Shifting left refers to moving security sooner in the development process, something that seems to be sorely needed in today’s applications. Nowhere is this more true than in the world of open-source software.
Software built today heavily leverages open-source software, a vast ecosystem of community-generated and public building blocks. Some studies have suggested that over 95% of software written today uses at least some open-source software as a building block [1]. Open-source code comes in many forms:
- Development frameworks that bundle key application functionality together into a unified set of APIs
- Libraries handling very specific functionality (logging, cryptography, etc.)
- Infrastructure such as servers or databases
- Container images
- Infrastructure as code provisioning modules
A big driver for leveraging open-source software is to alleviate the need to rebuild something that already exists, saving valuable time. Assembling the scaffolding of an application together with open-source components and building features and user experiences on top of it all is a common pattern to rapidly deliver software. Speed and consistency encapsulate some of the key opportunities of leveraging the open-source ecosystem.
Opportunity, however, doesn’t exist without risk. Risk in the open-source ecosystem could mean stability of a particular dependency due to a lack of maintenance [2]. Risk also comes from vulnerabilities in the code itself, in direct or transitive libraries (e.g., dependencies of dependencies). These issues are similar to software security issues found in any custom-written software, injection, hardcoded secrets, dangerous API primitives used, and so on. Legal issues also crop up with the sprawl of licenses used in open-source projects, creating complexities around use restriction, modification, or openness of the final product.
Managing the security around open-source software is a critical activity for development and security teams alike. Popular maturity models like the BSIMM and OpenSAMM have incorporated activities into their measurement criteria for how to build a mature software security program.
What to Do About It
As is the case in many parts of security, an effective strategy for managing open-source risk happens in multiple layers. Each of these layers plays an important part, these are summarized following the NIST CSF functions below.
Identify
Deploy a software composition analysis (SCA) capability. Doing so empowers teams to create and maintain an open-source component inventory inclusive of versions and licenses. An SCA tool, whether open-source or commercial can also help organizations build out a software asset inventory, aligning to the second CIS critical security control.
Collecting a software-bill-of-materials (SBOM) from commercial software vendors also provides this level of insight into software you would otherwise never have. This includes but is not limited to:
- Software and frameworks that make up the final build
- Versions of all software included
- Details about the build environment
Protect
Depending on the development environments, teams can set release gates in CI/CD pipelines around software security conditions. Taking this action, in essence, codifies policy into build and release tooling. Security and product teams can fail or flag builds that:
- Have a library detected with a high-risk vulnerability in it
- Has a reachable vulnerability (if SCA tooling supports this analysis) is present at a given risk level
- Contains a license that does not align with the organization’s legal risk tolerance
Detect
An SCA platform should provide teams the ability to analyze versions of libraries running for associations with known vulnerabilities. Vulnerabilities are typically associated with public CVE’s or proprietary vendor research databases. Development teams should ideally be able to access these insights readily. Providing security data alongside other telemetry they use on a daily basis helps alleviate the overhead to building quality software. Aggregated alerts also enables security teams to rapidly gather insight across development teams and product lines.
Respond
Encouraging and supporting a culture of keeping libraries up to date goes a long way in improving security and software stability. If a critical issue in a software component arises, such as the now-infamous log4j remote code execution issue (CVE-2021-45105), teams must respond quickly. Knowing what libraries to upgrade is critical. But so is actually being able to upgrade them without breaking core functionality of the system as well. An SCA capability should provide insight into whether vulnerable code in a library is being used. This provides an additional layer of insight around prioritization.
Recover
A large part of recovery falls down on people and process instead of technology. Security teams can and should however be laying the groundwork for development teams to easily understand whether they have recovered a system to a secure, compliant, and expected baseline. Codifying policy into testable artifacts helps empower developers to take ownership over security as a property of quality in their codebase.
Concluding Thoughts
Open-source software is inevitable and it is critical in today’s software development ecosystem. Tools, processes, and culture change are all needed to embrace and secure the open-source software that our software depends on. This embrace needs to also keep developer experience front and center.
