4 MIN READ
Picture the open source dependency graph on a typical production app. Five hundred packages on a small backend, two thousand on a typical frontend, every one of them a thing that can carry a vulnerability into the build. The tooling exists, the standards exist, the platform support sits ready, and what has not happened is the adoption.
Here is the part worth knowing. The SCA tools (Snyk, Sonatype, Mend, GitHub Dependabot, GitLab Dependency Scanning) all shipped the false positive rate down, the remediation guidance up, the CI/CD integration standard in 2024 and 2025. The SBOM generators (Syft, cdxgen, SPDX tooling) all produce the standard format, all run in CI, all attach to the build artefact. The SLSA framework shipped the supply chain levels and the attestation tooling alongside. The package signing tooling (Sigstore, cosign, in toto) all produce the signed package, and the major registries (npm, PyPI, Maven Central) all support the signing. The plumbing works. The procurement decisions, the security policy, the on call rotation that would turn the plumbing into a default have not followed.
What has matured
The SCA tooling sits at the top of the list of what shipped in 2024 and 2025. Snyk, Sonatype, Mend, GitHub Dependabot all do the dependency scanning, the vulnerability matching, the remediation guidance, and the CI/CD integration, and the false positive rate that defined the early 2020s has dropped into a range a developer can actually work with. SBOM generation came along at the same time. Syft, cdxgen, and the SPDX tooling all produce a usable artefact in the build pipeline, and the output attaches to the release rather than living in a separate document the security team has to chase. Vulnerability databases (NVD, GHSA, OSV) round it out. They all sit standard, machine readable, and they feed the SCA tools directly. Platform support finishes the list. GitHub, GitLab, JFrog, and Sonatype all ship the open source security workflow as a first class feature rather than a separate integration the team has to wire up. The four pieces together have produced the maturity the rest of the stack can build on.
What has not matured
The adoption gap sits at the top of the list of what is still blocking the full open source security story in 2026. The tooling is there. The standards are there. The platform support is there. Most enterprises are still running blind, because no one wired the procurement requirement, the on call rotation, the security policy review into the same workflow. Supply chain attestation comes next. The SLSA framework ships with the levels and the tooling. The build pipeline rarely produces the attestation, and the consumer side cannot verify the artefact came from the build they trust. Package signing verification rounds it out. The signing tooling is there. The registry support is there. The verification on the consumer side rarely runs, which means a tampered package can still land in the build without the alert. The three together are the difference between the open source security stack that produces a clean audit and the one that catches the tampered package before the install.
How to actually close the gap
Three moves, and they are not the same kind of move. Adopt the SCA tooling first. The dependency scanning, the vulnerability matching, the remediation guidance, the CI/CD integration all ship as a default option now, and the visibility it produces is what the rest of the work sits on. Generate the SBOM next, every build and every release, because the SBOM is what the vulnerability tracking, the compliance reporting, and the supply chain attestation all depend on. Without it, the rest of the work has nothing to read. Implement the package signing verification on the consumer side last. Configure the build to refuse the unsigned package, rotate the signing keys on a cadence, and verify the signature before the install. The supply chain attack the signing catches is rare, but the cost when one lands can wreck a security budget for the rest of the decade. The CISO who does all three closes the gap. The CISO who does one or two has the visibility, has the documentation, but still ships the unsigned package.
The bottom line
Adopt the SCA tooling. Generate the SBOM. Implement the package signing verification. The plumbing has been built. The standards have shipped. The platform support sits in place. The CISO who treats the adoption as a procurement problem rather than a research project is the one who closes the gap in 2026.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
