Maximizing Return on Investment When Securing Our Supply Chains: Where to Focus Our Limited Time to Maximize Reward

Editor's Note: The following is an article written for and published in DZone's 2025 Trend Report, Software Supply Chain Security: Enhancing Trust and Resilience Across the Software Development Lifecycle.

The goal of DevOps and DevSecOps — and whatever future contractions come next — has been to break down walls, but in practice, it usually means that developers take on a greater burden. Now, developers are not just responsible for delivering a satisfactory product on time, but also managing the operations and security of the product. This begs the question: Is it possible for developers to accomplish all of this? The answer is yes, but only if we spend our time wisely.

In this article, we will delve into practical steps to build and grow an automated security process that alleviates many of the burdens of securing our software supply chain that can bog us down in the midst of tight schedules and an ever-growing backlog.

Implications of Supply Chain Security

The advent of supply chain security (SCS) and DevSecOps means that the scope of our development work has grown significantly. We are now responsible for:

• Knowing every dependency that makes it into our product, including transitive ones many levels down
• Reading and understanding Common Vulnerabilities and Exposures (CVE) reports
• Understanding the legal implications of different licenses
• Advising legal and security teams and resolving issues presented by these teams
• Fixing any problems when any of these processes do not go smoothly

In many teams, there is already more work than people to complete it, so how do we accomplish our existing tasks while taking on this additional load? The answer is understanding what is actually needed and automating it.

Automate

It is impossible to manually check our supply chain for each commit for any reasonably sized product. Each seemingly benign library can contain a critical future vulnerability or a nested license that is impermissible. We must always be diligent and minimize our dependencies, but we reach a point where it becomes intractable to manually track all our dependencies. The solution lies in automating our security process, and the first step in doing so is to understand what our security process needs to accomplish.

Understand the Security Process

As with continuous integration/continuous delivery (CI/CD), there is no one-size-fits-all approach. While patterns may arise, the specifics of our security process will vary. The first step is to understand what our security process, and our CI/CD process in general, should accomplish:

• What artifacts does our process need to deliver?
• What reports should accompany our artifacts?
• What security measures must be included (such as artifact signing and build process verification)?
• What is our desired security threshold?
  • What are the timelines for mitigating different vulnerabilities?
  • Which vulnerabilities are show-stoppers?
  • Which vulnerabilities can be mitigated in the next release?
• What licenses are permissible?
• What level of traceability or attestation is required?

The answers to these questions will vary by product — a military product will have different requirements than an internal product residing behind a DMZ. The important takeaway is to understand what is required of our product, create a meaningful starting point, and build on it until all of our requirements are satisfied.

Start With the Basics

Automating this process can seem overwhelming at first, but it’s not if we focus on starting small and growing. Improving the process 20% today is far better than improving the process 100% some ethereal time in the future. The first place to start is by generating a software bill of materials (SBOM). This single document describes all of the dependencies in our supply chain and provides visibility into what our product relies on. 

We must ensure that the SBOM we generate is:

• Comprehensive: The entire dependency graph must be accounted for, including transitive dependencies, build dependencies used to create artifacts (such as compilers), and dependencies in container images.
• Readable: The SBOM should be generated in a format that is parsable by tools and readable by developers, such as JSON or YAML. Human readability is essential for easier troubleshooting and understanding which dependencies are problems (or a suitable tool can be used to visualize the dependency graph).

Having a comprehensive and readable SBOM seems basic, but it is essential to securing our supply chain. We cannot audit or secure our supply chain if we do not know what goes into our product. 

Note: An SBOM may provide a malicious actor with information about the attack surface of our product. We should consider carefully whether to deliver the SBOM with our product based on our security requirements.

Shifting Security Left

Generating an SBOM is a good first step, but it’s not the end of the line. Having a security process in place should prevent vulnerabilities or compromising artifacts in our supply chain (such as impermissible licenses) from making it into our product. The next step is to analyze our SBOM and automatically fail our build if a dependency does not meet our standards. These standards include:

• No vulnerabilities that cross our security threshold
• No incompatible licenses
• No deprecated or unmaintained dependencies

When any of these standards are not met, we should break our build. The only way to guarantee that our supply chain is secure is to ensure that a substandard dependency is never introduced in the first place. In practice, though, we may be starting with a product that already has substandard dependencies, and we are trying to weed them out. We can’t eat the entire elephant in a single bite, so we have to take it one step at a time.

A few pragmatic approaches are to:

• Pick your battles wisely: We should be honest about what’s a showstopper and what’s not. Having a deprecated dependency with zero known vulnerabilities may not be a showstopper, but having an incompatible license likely is. Start with breaking the build for standards that matter most and then gradually add standards as break-worthy.
• Raise the security threshold over time: At first, only break the build for critical or high vulnerabilities. Once these vulnerabilities are mitigated, keep increasing the threshold until our desired security threshold is reached.

These approaches require discipline: The standards should be raised over time and not kept relaxed indefinitely. Throughout this entire process, the goal should always be to start small and improve. Gradual improvement today is better than a perfect solution that never comes.

Other Considerations

With a solid automated SCS process in place, we can also add the following:

• Static code analysis
• Dynamic analysis of our executing product
• Third-party tools that aid in mitigation, such as tools that suggest mitigation for known vulnerabilities — or even automatically create pull requests (PRs) for mitigating vulnerabilities

Some of these tools may not even use our SBOM, so they can be pushed further left in the delivery process. For example, some tools scan the code in a repository or the code for each commit to ensure that it does not introduce any vulnerabilities. The goal is to fail the build as early as possible, so if tools allow us to check our code or commits — even before we build it — always lean on shifting as far left as possible.

Audit and Improve

Instituting SCS is not something we do once. It’s a process that must be continually audited and improved. Over time, requirements will change, security constraints may tighten, and issues will arise. Our automated process should always be in alignment with our current needs. A few ways we can continually improve our security process are to:

• Watch for manual tasks: Look for manual tasks that keep cropping up. For example, has the legal team been catching impermissible licenses in our product? Improve the license check in the automated process until no impermissible licenses are found again.
• Get out ahead of other teams: Look for opportunities to lessen the load on other teams. For example, has the security team been delaying releases because the security compliance checks are too burdensome? Improve the process by asking them what would help the process along and automate it (e.g., generating the vulnerability report in a different format, catching more vulnerabilities before sending the product to the security team, or auditing).

There are always opportunities for improvement. The driving force for the long-term life of our automated SCS should be automating processes that free us up to focus on developing a quality product.

Conclusion

The introduction of DevOps and DevSecOps has increased the burden on developers. It can be easy to lose track of our main goal: delivering our product on time and under budget. While taking on new roles, such as operations and security, can seem like a Sisyphean endeavor, it doesn’t have to be. We have to focus on what provides the greatest bang for the buck, including:

• Automating as much as possible
• Catching problems as early as possible
• Mitigating them as easily as possible (preferably with automated PRs)

Putting these principles into practice ensures that we can cover the roles of operations and security in addition to our main goal: timely delivery of a product that meets the needs of our customers.

This is an excerpt from DZone's 2025 Trend Report, Software Supply Chain Security: Enhancing Trust and Resilience Across the Software Development Lifecycle.

Read the Free Report