When a fintech startup's security team ran an open source security audit ahead of a Series B due diligence process in late 2024, they expected a clean report. Instead, the audit surfaced 340 transitive dependencies with no maintained upstream, 12 packages with typosquat-adjacent names, and a build pipeline that pulled unpinned versions from npm on every deploy. None of that showed up in their existing SCA dashboard, because a dependency scan and a security audit are not the same exercise. The distinction matters more every year: the 2024 xz-utils backdoor (CVE-2024-3094), discovered by chance on March 29, 2024, was inserted by a trusted maintainer over two years of legitimate-looking commits — exactly the kind of risk a CVE feed cannot catch but a proper audit is built to find. This glossary entry breaks down what an open source security audit actually covers, how it differs from tools like Aikido Security, and what a rigorous one costs in time and money.
What does an open source security audit actually check?
An open source security audit checks four things a vulnerability scanner does not: provenance, maintenance health, license exposure, and build integrity. Provenance review verifies that a package's published artifact actually matches its source repository — the exact gap attackers exploited in the 2021 ua-parser-js compromise, when a maintainer's npm account was hijacked and three versions were published with cryptomining and credential-stealing payloads baked in, invisible to anyone checking GitHub. Maintenance health looks at bus-factor risk: how many maintainers a project has, when it last received a security-relevant commit, and whether it's still receiving patches at all — Log4j had a single primary maintainer volunteering unpaid hours when Log4Shell (CVE-2021-44228) broke on December 10, 2021, and that concentration is a scored risk factor in most audit frameworks today, including the OpenSSF Scorecard's "Maintained" and "Contributors" checks. License exposure flags copyleft obligations (GPL, AGPL) buried three or four levels deep in a dependency tree. Build integrity confirms the CI/CD pipeline itself — not just the code — hasn't been tampered with, following SLSA (Supply-chain Levels for Software Artifacts) provenance requirements up to Level 3.
How is a security audit different from a routine SCA scan?
An SCA scan matches installed package versions against a CVE database; an audit evaluates whether the software supply chain producing those packages can be trusted in the first place. Sonatype's 2024 State of the Software Supply Chain report counted over 512,847 malicious open source packages published across the year — packages that were malicious from the moment they were published, meaning they had zero CVEs and would pass every SCA scan clean because no vulnerability had been assigned yet. An audit's malicious-package and reputation checks are designed to catch exactly that gap: unusual install scripts, obfuscated payloads, sudden maintainer changes, or a package that mimics a popular name (electorn vs. electron, reqeusts vs. requests). SCA tools are necessary and fast — most run in CI on every commit — but they answer "does this known-bad version exist in my tree," while an audit answers "should this dependency be trusted at all." Mature programs run both: continuous SCA for day-to-day patching, plus a periodic (typically quarterly or pre-release) audit for the trust questions SCA can't ask.
What frameworks and standards define audit scope?
Three frameworks set the baseline for what a credible open source security audit measures: the OpenSSF Scorecard, SLSA, and NIST's Secure Software Development Framework (SSDF, SP 800-218). OpenSSF Scorecard produces an automated 0–10 score across 18 checks — code review coverage, branch protection, dangerous workflow patterns, dependency pinning — and is used by Google, and increasingly by enterprise procurement teams, as a fast triage signal before a deeper manual review. SLSA defines four build-integrity levels, from Level 1 (documented build process) to Level 4 (two-person reviewed, hermetic, fully reproducible builds); most open source projects sit at Level 0 or 1 today, which is itself a finding worth reporting to a buyer or auditor. NIST SSDF, referenced directly in Executive Order 14028 and required for federal software attestation since 2023 via the CISA self-attestation form, adds process controls: how vulnerabilities are disclosed, how patches are verified, and whether an SBOM (software bill of materials) is produced and kept current. An audit that doesn't map findings back to at least one of these frameworks is closer to a checklist than a security assessment.
How long does an open source security audit take, and what does it cost?
A focused audit of a single mid-sized codebase (roughly 200–500 direct and transitive dependencies) typically takes between 3 and 10 business days and costs $8,000–$40,000 when performed by an outside firm, depending on depth — a Scorecard-style automated pass sits at the low end, while a manual provenance and build-integrity review with pen-testing of the CI pipeline sits at the high end. Enterprise-wide audits covering hundreds of repositories and thousands of unique packages commonly run 4–8 weeks and scale into six figures, which is why most organizations pair an annual or pre-acquisition deep audit with continuous automated monitoring in between, rather than re-running the full manual process every quarter. Gartner's 2023 guidance projected that by 2025, 45% of organizations worldwide would have experienced a software supply chain attack — up threefold from 2021 — which is the underlying pressure pushing audit cadence from "once, for compliance" to "continuously, for risk reduction."
How does Aikido Security approach open source audits?
Aikido Security, founded in Ghent, Belgium in 2022, bundles SCA, secrets detection, SAST, IaC scanning, and container/cloud posture checks into a single dashboard aimed primarily at small-to-mid-size engineering teams that want one tool instead of five. Its open source coverage is strongest on the automated-scanning layer: dependency vulnerability matching, license flags, and reachability analysis that tells a team whether a vulnerable function is actually called by their code, which cuts down noisy alerts considerably. Where Aikido's model is intentionally lighter is on the deeper audit dimensions covered above — build provenance verification, SLSA-level attestation, and maintainer/bus-factor scoring aren't the product's center of gravity, because Aikido is built as a fast, low-friction scanner rather than a supply-chain-integrity platform. That's a reasonable tradeoff for a team of 10 engineers shipping a single SaaS product; it's a gap for organizations under SOC 2, FedRAMP, or EO 14028 attestation pressure that need provenance and SBOM evidence, not just a clean vulnerability list, to pass a customer security questionnaire or federal audit.
Does an audit replace continuous monitoring, or supplement it?
An audit supplements continuous monitoring — it never replaces it, because the open source ecosystem changes faster than any point-in-time review can account for. The average application pulls in a new transitive dependency version multiple times per week through routine npm install or pip install runs, and Sonatype's data shows the median time between a malicious package's publication and its removal from a registry is measured in days, not months — a window an audit performed six months ago has no visibility into. The right model treats an audit as a calibration event: it sets the baseline (which frameworks you're measuring against, which packages are flagged as high-risk, what your current SLSA/Scorecard posture is), and continuous monitoring enforces that baseline on every commit and every new dependency introduced afterward. Teams that only audit annually and skip continuous enforcement in between are the ones still finding out about a compromised package from a customer's security team instead of their own tooling.
How Safeguard Helps
Safeguard is built around the audit-plus-monitoring model rather than treating them as separate purchases. Our platform runs OpenSSF Scorecard-aligned checks, SLSA provenance verification, and maintainer/bus-factor scoring continuously against every dependency in your tree — not just at scan time, but on every pull request and every new transitive package pulled into a build. We generate and maintain a live SBOM mapped to NIST SSDF and CISA attestation requirements, so the evidence a periodic manual audit produces doesn't go stale the day after it's delivered. For teams evaluating Aikido or similar all-in-one scanners, Safeguard is designed to sit deeper in the supply chain layer: reachability-aware vulnerability triage plus provenance and build-integrity verification in one pipeline, so you're not stitching together a Scorecard run, a separate SBOM tool, and a manual audit vendor to answer the questions a serious buyer, regulator, or enterprise customer will actually ask. If your last open source audit is more than a quarter old, that's the fastest way to tell whether it's time for continuous coverage instead of another one-off engagement.