Open source is ubiquitous within the enterprise. From desktop applications to server-based deployments to cloud-based services, open source is everywhere. For security conscious organizations, identifying all the open source software deployed across the extended enterprise, and tracking their vulnerability status, is vital to ensuring security and managing risk.

ActiveState can help by providing a single, central location from which to identify all open source across the organization, as well as monitor status changes over time, resulting in faster remediation response times.  

Unfortunately, identifying all the open source components in all of the software your organization builds, deploys, and makes use of is rarely as straightforward as it should be. Key discoverability issues include:

  • Ghost Dependencies – open source packages (i.e., top-level dependencies) typically have one or more transitive dependencies, each of which can have one or more layers of dependencies themselves.  Transitive dependencies are also referred to as ghost dependencies because they’re rarely tracked with the same level of scrutiny as top-level dependencies, and because they can change each time a new version of a top-level dependency is released.

  • Binary Scanners – most organizations deploy pre-built software. Even those organizations that build their own software typically import open source packages as prebuilt binaries rather than source code. As a result, they rely on binary scanners to essentially reverse engineer the software in order to generate a complete Software Bill of Materials (SBOM) that contains all the open source components (top-level packages and transitive dependencies) they’ve deployed. Unfortunately, anyone who has run more than one scanner against their software can attest to the fact that no two scans produce the same dependency catalog. As a result, generating a definitive Software Bill Of Materials (SBOM) remains problematic. 

  • Tool Fatigue – open source can be located in code repositories, across server file systems, or in containers on various cloud environments. And it could be deployed as source code, individual binaries, or else compiled into frameworks or applications. As a result, organizations may need to deploy multiple tools (typically Software Composition Analysis, or SCA tools) to help identify all the open source components they have in play. Deploying, learning, maintaining, and updating multiple tools over time can add significant drag to any organization’s operations. 

For security professionals, discovering all the open source in the organization is only the first – though crucial – step, since you can’t secure what you don’t know about. But open source is rarely static. Today’s SBOMs may be woefully out of date by this time next month as software is updated, new versions are deployed, and vulnerabilities get patched. To be effective, security personnel need the ability to track and observe open source over time. Key observability issues include:

  • Security Posture – the frequency of open source software vulnerability reporting continues to escalate, not only because more and more organizations are taking advantage of open source software, but also because more organizations are reporting the vulnerabilities they find. While this trend can potentially make everyone more secure, it offers little benefit if the organization can’t identify vulnerabilities in a timely manner. 

  • Auditability – when something goes wrong, it’s vital to be able to trace the error back to a root cause in order to ensure the same mistake doesn’t happen again. For this reason, it’s key to be able to track changes to open source software as they happen, but this level of forensic audit is rarely available. 

Open Source Discovery & Observability Solutions

While multiple solutions from SCA tools to SBOMs to binary repositories exist to help with many of the open source discovery and observability issues, cobbling together multiple solutions may introduce more issues (binary scanners, tool fatigue, escalating costs to maintain, etc.) than they resolve. 

In contrast, ActiveState offers a single platform that can not only discover all the open source software you have deployed, but also track each component over time. Some of the key features include:

  • Agnostic Discovery – ActiveState is able to scan most popular resources no matter the ecosystem or deployment environment, including Kubernetes clusters/helm charts, Docker registries, GitHub repositories, SBOMs, open source language manifest files, and more. A single solution that can ingest all popular formats eliminates tool fatigue. 

  • Build Dependency Tree – ActiveState is a universal build system that can automatically build open source software securely from vetted source code. This means ActiveState generates a complete dependency tree for each built artifact inclusive of transitive dependencies, OS-level dependencies, shared libraries, and more, eliminating the issue of ghost dependencies while producing a complete catalog of all open source components.

  • Vulnerability Identification – ActiveState continually monitors the vulnerability status of each open source component, generates a vulnerability report per project, and sends notifications to key stakeholders, decreasing Mean Time To Identification (MTTI). In addition, an enterprise-wide vulnerability dashboard allows all stakeholders to quickly filter and identify which projects, containers, applications, etc contain critical vulnerabilities (for example), or else search for a known vulnerability (e.g., log4j) in order to instantly identify which projects and deployments have yet to be remediated. 

  • Auditable History – ActiveState maintains a git-like snapshot of every change to a project, including who made which change(s) when, and where. In this way, it’s possible to track changes to a project by environment location and team member(s) over time, facilitating troubleshooting, root cause analysis, and regulatory compliance.
    • Additionally, ActiveState creates an SBOM and Provenance Attestation for each snapshot (and each artifact within the snapshot), ensuring you can always trace a component back to its origin, as well as verify the security and integrity of any current or previous build.

Conclusions: The Benefits of Open Source Discoverability & Observability Solutions

Managing application security risk is a critical function within the enterprise, as it represents a key vector of attack for bad actors looking to compromise either your software supply chain (typically by compromising open source components during the import or build process), or else by exploiting a vulnerability before it can be fixed. 

While you could spend the time and resources to integrate multiple point solutions to address discoverability (e.g., SCA tools, Application Security Posture Management (ASPM), etc) and observability (e.g., artifact repositories, vulnerability trackers, etc.), the cost to update and maintain such a solution escalates over time. Instead, a single platform like ActiveState can provide:

  • Universal discoverability
  • End-to-end observability
  • Decreased MTTI

All of which means faster response times for issue remediation by gaining clear insights into open source software utilization.

Next Steps

Read our datasheet overview on how you can discover, manage, and secure your open source software across multiple ecosystems and deployment environments.