When it comes to trust in software, ActiveState’s recent supply chain security survey shows that one-third of organizations implicitly trust open source repositories, while the other two-thirds take a “trust but verify” approach, implementing at least some controls to limit risk.
More security conscious-organizations prefer to build their open source components from source code, while some (~15%) have implemented a zero trust framework in order to treat all open source code as untrusted across the entire software development process. But zero trust frameworks are both expensive and time-consuming to implement. In the meantime, the industry is faced with an ever-escalating number of supply chain attacks (as understood from Sonatype’s latest report and Anchore’s survey report) affecting a growing number of software development organizations:
So how can you mitigate the risk of the open source components you work with while controlling for costs? Shift security left:
Source: IBM System Science Institute: Relative Cost of Fixing Defects
Starting with secure, trusted open source artifacts before your developers write their first line of code is the best way to control costs. And for 80% of projects that never update third-party libraries after including them in their codebase (Per Veracode’s report), it’s even more critical to ensure they import secure components in the first place.
Why organizations can’t trust the open source components their developers use
DevSecOps and the “Shift Left” approach to resolving security issues early have been around for more than a decade but has never gained a tremendous amount of adoption. Some of the countering arguments we’ve heard include:
- “Our current practice of implicitly trusting the packages we get from public repositories is no better or worse than the rest of the software industry.”
- “My developers need to focus on coding, not security. That’s what I have a security team for.”
- “My developers are smart people. They’ll route around any controls I put in place that limit their ability to get their job done.”
All of which are indicative of why the status quo has remained unchanged despite the growing threat of public repository exploits like:
- Typosquatting – the practice of uploading compromised packages that are named similar to popular packages (i.e., matplatlib compared to matplotlib)
- Dependency Confusion – similar to typosquatting, compromised packages are named similar to proprietary packages a target company may use internally. The confusion arises when a build tool prioritizes dependencies in public repositories over private ones.
- Author Impersonation – the process of compromising a public repository that has poor identity and access management controls.
- Compromised Packages – the process of compromising a public repository and uploading a malware version of a popular package.
Even those organizations that choose to build their open source components from source code are not immune to trust issues, since they have to deal with a growing number of supply chain attacks that target their build and test infrastructure, including threats from:
- Compromised Source Code – without proper controls or a strict vetting process, organizations can unwittingly import and use source code infected with trojans/malware.
- Compromised Build Service – builds performed on developer machines rather than dedicated, locked down build servers can more easily be compromised by attackers.
- Bypassed CI/CD – developers that need access to packages not in their local repository may download them directly from public repositories. This bypasses the organization’s vetting process, and can result in the use of compromised dependencies.
- Bad Dependencies – prebuilt packages that contain malware may be incorporated as dependencies of other packages, further compromising the runtime environment.
Any and all of these threats can result in untrusted open source components being imported, built and used within an organization, compromising the security and integrity of the software being developed.
Why trust ActiveState’s Trusted Artifacts?
ActiveState has been supplying secure open source distributions to the software industry for more than twenty years, initially via hand-built runtime environments, but lately via an automated platform that implements a number of security best practices in order to ensure the security and integrity of the open source components it produces.
For example, Google’s Supply-chain Levels for Software Artifacts (SLSA) best practice provides a set of requirements that can help decrease the risk of compromise for artifacts built from source code:
The higher the SLSA level, the less the risk associated with building artifacts from source code. Unfortunately, Google says it can take years to create an automated system capable of achieving a SLSA Level 4 rating, and we would agree. Our ActiveState Platform meets most of the requirements for SLSA level 4, but has taken multiple years to achieve, and continues to be under development.
However, employing the ActiveState Platform’s secure build service can significantly de-risk the building of open source language components since it provides:
- Reproducible builds from an internal library of vetted source code that is retained indefinitely.
- Benefit: eliminate “can’t reproduce the build” situations, even for EOL products.
- Scripted, parameterless builds using a dedicated build service.
- Benefit: eliminate build script hacks that can compromise builds.
- Container-based build environments that are ephemeral, isolated, and hermetically sealed (i.e., no access to the internet).
- Benefit: eliminate the chance for bad actors can inject malware into the build process.
- Verifiable builds that are dependency complete and feature both non-falsifiable provenance (i.e., all dependencies can be traced backed to their source) and a Software Bill Of Materials (SBOM).
- Benefit: complete transparency over what is in your build, and where the components came from.
As a result, when binary repositories like JFrog Artifactory are populated with open source language artifacts built by ActiveState, organizations gain both security and control, resulting in decreased software development risk.
Convert ‘untrusted’ open source components to ‘trusted’ open source artifacts with ActiveState
Whether you currently proxy public repositories in order to provide your developers with the open source packages they need, or else build them from source code, you are exposing your organization to undue–and growing–risk. But the cost of implementing a robust set of security controls and tools, or even creating a zero-trust environment, can be prohibitive.
For this reason, ActiveState has created our Trusted Artifact Subscription that can populate artifact repositories like JFrog Artifactory with secure open source language components. Key features include:
- A vetting and ingestion process in order to weed out bad source code.
- An integral supply chain that archives all the source code and protects it from tampering.
- A cross-platform build system that generates trustworthy artifacts in a repeatable way, as well as a machine-readable Software Bill of Materials (SBOM)
- A CVE-aware dependency resolution system that makes vulnerability remediation typically a question of hours instead of days or weeks.
As a result, you can ensure your software projects not only start with a secure set of packages, but that those packages can be updated and remediated as vulnerabilities crop up over time.
Next steps
Understand how ActiveState can help you decrease the risk and overhead of managing open source language packages in Artifactory. Let us walk you through how the solution can fit your team’s (or teams’) needs.
Need more information?
- Read our datasheet about ActiveState Platform’s Secure Build Service
- Read more about Shifting Security Left with the ActiveState Platform
