In previous blog posts we have covered the risks of open source software (OSS) and security best practices to manage that risk. From there we zoomed in on the benefits of tightly coupling two of those best practices (SBOMs and vulnerability scanning).
Now, we'll dig deeper into the practical considerations of integrating this paired solution into a DevSecOps pipeline. By examining the design and implementation of SBOMs and vulnerability scanning, we'll illuminate the path to creating a holistic open source software (OSS) risk management program.
Learn about the role that SBOMs for the security of your organization in this white paper.
How do I integrate SBOM management and vulnerability scanning into my development process?
Ideally, you want to generate an SBOM at each stage of the software development process (see image below). By generating an SBOM and scanning for vulnerabilities at each stage, you unlock a number of novel use-cases and benefits that we covered previously.
Let's break down how to integrate SBOM generation and vulnerability scanning into each stage of the development pipeline:
Source (PLAN & CODE)
The easiest way to integrate SBOM generation and vulnerability scanning into the design and coding phases is to provide CLI (command-line interface) tools to your developers. Engineers are already used to these tools—and have a preference for them!
If you're going the open source route, we recommend both Syft (SBOM generation) and Grype (vulnerability scanner) as easy options to get started. If you're interested in an integrated enterprise tool then you'll want to look at AnchoreCTL.
Developers can generate SBOMs and run vulnerability scans right from the workstation. By doing this at design or commit time developers can shift security left and know immediately about security implications of their design decisions.
If existing vulnerabilities are found, developers can immediately pivot to OSS dependencies that are clean or start a conversation with their security team to understand if their preferred framework will be a deal breaker. Either way, security risk is addressed early before any design decisions are made that will be difficult to roll back.
Build (BUILD + TEST)
The ideal location to integrate SBOM generation and vulnerability scanning during the build and test phases are directly into the organization's continuous integration (CI) pipeline.
The same self-contained CLI tools used during the source stage are integrated as additional steps into CI scripts/runbooks. When a developer pushes a commit that triggers the build process, the new steps are executed and both an SBOM and vulnerability scan are created as outputs.
Check out our docs site to see how AnchoreCTL (running in distributed mode) makes this integration a breeze.
If you're having trouble convincing your developers to jump on the SBOM train, we recommend that developers think about all security scans as just another unit test that is part of their testing suite.
Running these steps in the CI pipeline delays feedback a little versus performing the check as incremental code commits are made as an application is being coded but it is still light years better than waiting till a release is code complete.
If you are unable to enforce vulnerability scanning of OSS dependencies by your engineering team, a CI-based strategy can be a good happy medium. It is much easier to ensure every build runs exactly the same each time than it is to do the same for developers.
Release (aka Registry)
Another integration option is the container registry. This option will require you to either roll your own service that will regularly call the registry and scan new containers or use a service that does this for you.
See how Anchore Enterprise can automate this entire process by reviewing our integration docs.
Regardless of the path you choose, you will end up creating an IAM service account within your CI application which will give your SBOM and vulnerability scanning solution the access to your registries.
The release stage tends to be fairly far along in the development process and is not an ideal location for these functions to run. Most of the benefits of a shift left security posture won't be available anymore.
If this is an additional vulnerability scanning stage—rather than the sole stage—then this is a fantastic environment to integrate into. Software supply chain attacks that target registries are popular and can be prevented with a continuous scanning strategy.
Deploy
This is the traditional stage of the SDLC (software development lifecycle) to run vulnerability scans. SBOM generation can be added on as another step in an organization's continuous deployment (CD) runbook.
Similar to the build stage, the best integration method is by calling CLI tools directly in the deploy script to generate the SBOM and then scan it for vulnerabilities.
Alternatively, if you utilize a container orchestrator like Kubernetes you can also configure an admission controller to act as a deployment gate. The admissions controller should be configured to make a call out to a standalone SBOM generator and vulnerability scanner.
If you'd like to understand how this is implemented with Anchore Enterprise, see our docs.
While this is the traditional location for running vulnerability scans, it is not recommended that this is the only stage to scan for vulnerabilities. Feedback about security issues would be arriving very late in the development process and prior design decisions may prevent vulnerabilities from being easily remediated. Don't do this unless you have no other option.
Production (OPERATE + MONITOR)
This is not a traditional stage to run vulnerability scans since the goal is to prevent vulnerabilities from getting to production. Regardless, this is still an important environment to scan. Production containers have a tendency to drift from their pristine build states (DevSecOps pipelines are leaky!).
Also, new vulnerabilities are discovered all of the time and being able to prioritize remediation efforts to the most vulnerable applications (i.e., runtime containers) considerably reduces the risk of exploitation.
The recommended way to run SBOM generation and vulnerability scans in production is to run an independent container with the SBOM generator and vulnerability scanner installed. Most container orchestrators have SDKs that will allow you to integrate an SBOM generator and vulnerability scanner to the preferred administration CLI (e.g., kubectl for k8s clusters).
Read how Anchore Enterprise integrates these components together into a single container for both Kubernetes and Amazon ECS.
How do I manage all of the SBOMs and vulnerability scans?
Tightly coupling SBOM generation and vulnerability scanning creates a number of benefits but it also creates one problem; a firehose of data. This unintended side effect is named SBOM sprawl and it inevitably becomes a headache in and of itself.
The concise solution to this problem is to create a centralized SBOM repository. The brevity of this answer downplays the challenges that go along with building and managing a new data pipeline.
We'll walk you through the high-level steps below but if you're looking to understand the challenges and solutions of SBOM sprawl in more detail, we have a separate article that covers that.
Integrating SBOMs and vulnerability scanning for better OSS risk management
Assuming you've deployed an SBOM generator and vulnerability scanner into at least one of your development stages (as detailed above in "How do I integrate SBOM management and vulnerability scanning into my development process?") and have an SBOM repository for storing your SBOMs and/or vulnerability scans, we can now walkthrough how to tie these systems together.
- Create a system to pull vulnerability feeds from reputable sources. If you’re looking for a way to get started here, read our post on how to get started.
- Regularly scan your catalog of SBOMs for vulnerabilities, storing the results alongside the SBOMs.
- Implement a query system to extract insights from your inventory of SBOMs.
- Create a dashboard to visualize your software supply chain’s health.
- Build alerting automation to ping your team as newly discovered vulnerabilities are announced.
- Maintain all of these DIY security applications and tools.
- Continue to incrementally improve on these tools as new threats emerge, technologies evolve and development processes change.
If this feels like more work than you're willing to take on, this is why security vendors exist. See the benefits of a managed SBOM-powered SCA below.
Prefer not to DIY? Evaluate Anchore Enterprise
Anchore Enterprise was designed from the ground up to provide a reliable software supply chain security platform that requires the least amount of work to integrate and maintain. Included in the product is:
- Out-of-the-box integrations for popular CI/CD software (e.g., GitHub, Jenkins, GitLab, etc.)
- End-to-end SBOM management
- Enterprise-grade vulnerability scanning with best-in-class false positives
- Built-in SBOM drift detection
- Remediation recommendations
- Continuous visibility and monitoring of software supply chain health
Enterprises like NVIDIA, Cisco, Infoblox, etc. have chosen Anchore Enterprise as their "easy button" to achieve open source software security with the least amount of lift.
If you're interested to learn more about how to roll out a complete OSS security solution without the blood, sweat and tears that come with the DIY route—reach out to our team to get a demo or try Anchore Enterprise yourself with a 15-day free trial.
Learn the container security best practices to reduce the risk of software supply chain attacks.
