Apache Struts CVE-2017-5638 had a patch available on March 7, 2017. Equifax didn't apply it, and attackers walked in through an unpatched web application starting in mid-May, exfiltrating data on 147 million people over 76 days before anyone noticed. That breach wasn't a novel zero-day or a nation-state exploit chain — it was a failure to implement controls that already existed in written form. OWASP had published its Top 10 Proactive Controls the year before, and "keep your libraries and frameworks updated" was already control C2. The gap between knowing the controls and implementing them in a real pipeline, across hundreds of repos and thousands of dependencies, is where most application security programs actually break down. This post walks through what the OWASP Top 10 Proactive Controls are, which ones matter most for teams shipping software with modern open-source supply chains, and how to operationalize them instead of just checking a box on a slide.
What are the OWASP Top 10 Proactive Controls?
The OWASP Top 10 Proactive Controls are a ranked list of ten security practices developers should build into software from the start, rather than bolt on after a pentest finds problems. Version 3, released in 2018 and led by Jim Manico and Katy Anton, lists them as: C1 Define Security Requirements, C2 Leverage Security Frameworks and Libraries, C3 Secure Database Access, C4 Encode and Escape Data, C5 Validate All Inputs, C6 Implement Digital Identity, C7 Enforce Access Controls, C8 Protect Data Everywhere, C9 Implement Security Logging and Monitoring, and C10 Handle All Errors and Exceptions. Unlike the OWASP Top 10 (which catalogs the most common vulnerability classes attackers exploit), the Proactive Controls are a builder's checklist — they map directly onto sprint work, code review checklists, and CI/CD gates. Every control on this list has a corresponding, well-known real-world failure: C2 failures produced Equifax; C5 and C4 failures produced the bulk of the injection flaws still sitting at #3 on the 2021 OWASP Top 10.
Why does C2 (leverage security frameworks and libraries) matter most for supply chain security?
C2 matters most because the average application now pulls in far more third-party code than first-party code, and most breaches trace back to a component, not a hand-written bug. A typical mid-size Java or JavaScript service depends, directly and transitively, on 150 to 800 open-source packages. The npm registry alone crossed 2 million published packages years ago, and a 2023 Sonatype analysis counted over 245,000 malicious packages uploaded that year — a number that has only grown since. The 2020 SolarWinds/Sunburst compromise and the December 2021 Log4Shell disclosure (CVE-2021-44228, CVSS 10.0, exploitable with a single crafted string in a log line) both show the same pattern: one compromised or vulnerable dependency, buried three or four levels deep in a dependency tree, becomes the blast radius for every application that ships it. Implementing C2 today means maintaining a real, machine-readable inventory of every component in every build — not a spreadsheet updated quarterly.
How do you implement C5 (validate all inputs) without slowing down releases?
You implement C5 by pushing validation to a shared, centrally-maintained library and enforcing it at the API boundary with automated tests, rather than asking every engineer to hand-roll sanitization in every controller. OWASP recommends allowlist (positive) validation over denylist patterns, validating for type, length, range, and format before any data reaches business logic. In practice, teams that treat this as a per-developer discipline see it decay within a few sprints — new hires don't know the local conventions, and deadline pressure skips the "boring" checks. Teams that instead bake validation into a shared middleware layer, enforce it with contract tests in CI, and fail the build on schema violations keep C5 coverage above 90% without adding review time. The 2021 OWASP Top 10 still ranks Injection at #3 across the industry seventeen years after it first appeared on the list in 2004 — proof that this control is well understood in theory and inconsistently applied in practice.
What does C9 (security logging and monitoring) actually require in a CI/CD pipeline?
C9 requires that every authentication event, access-control decision, input validation failure, and high-value transaction gets logged with enough context to reconstruct an incident, and that those logs are monitored, not just retained. OWASP's own Logging Cheat Sheet specifies logging who, what, when, and where for each event, while explicitly excluding secrets, session tokens, and full credit card numbers from log payloads — a distinction that matters because logging the wrong field creates a new data-exposure incident while trying to close a monitoring gap. For pipeline security specifically, this extends to build systems: dependency resolution events, package registry pulls, and CI job approvals need the same audit trail as application logins. The 2023 3CX supply chain attack was detected largely because downstream security vendors' monitoring flagged anomalous outbound connections from a signed, trusted binary — exactly the kind of behavioral signal C9 is designed to produce when logging is wired to real alerting instead of a log bucket nobody reads.
How does C7 (enforce access controls) apply to CI/CD pipelines and package registries?
C7 applies to CI/CD by requiring least-privilege, deny-by-default access for every identity that can touch a build — human or machine — not just for application end users. The control was written with web app roles in mind, but the same logic governs who can approve a merge, which service account can publish to an npm or PyPI registry, and which pipeline stage can pull secrets from a vault. The 2020 SolarWinds incident and later cases like the compromised CodeCov Bash Uploader (discovered April 2021, active undetected for roughly two months) both involved attackers reaching build infrastructure that had broader access than any single job actually needed. A concrete C7 implementation in a pipeline means scoped, short-lived tokens per job instead of one long-lived CI credential with organization-wide write access, mandatory two-person review on any change to publish or deploy permissions, and automatic revocation when a service account goes unused for 30 days.
Where do teams fail when implementing these controls at scale?
Teams fail most often at C2 and C9 because both require continuous inventory and continuous attention, not a one-time configuration. A control like C4 (encode and escape data) can be satisfied largely by adopting a templating framework once and moving on. C2, by contrast, requires knowing your dependency tree on the day of every release, not the day you last ran a scan — and a component that was safe in January can carry a critical CVE by March. Gartner and multiple vendor breach reports through 2023 and 2024 consistently list "unpatched or unknown third-party component" as a top-three initial access vector, alongside phishing and exposed credentials. The practical failure mode is volume, not ignorance: a security team of three or four people cannot manually triage thousands of dependency alerts a month across dozens of repositories, so the controls get implemented on paper (a policy doc, a tool license) but not in the pipeline that actually ships code.
How Safeguard Helps
Safeguard operationalizes C2, C7, and C9 directly inside the SDLC rather than leaving them as policy documents. Reachability analysis cuts through alert volume by determining whether a vulnerable function in a dependency is actually called by your application code, so teams stop triaging CVEs that can never be exploited in their specific build. Griffin AI reviews findings with the same context a senior security engineer would use — call paths, exploit maturity, exposure — and drafts the fix, while Safeguard's SBOM generation and ingest give you the continuous, build-time component inventory that C2 requires instead of a stale quarterly export. When a genuinely exploitable issue is confirmed, Safeguard opens an auto-fix pull request with the minimal version bump or patch needed, so the control gets implemented in the pipeline, not just documented in a wiki.