Could You Identify a Vulnerable Website Dependency Today?
Why npm audit alone is not a supply-chain strategy, and how lockfiles, dependency review, and a lightweight SBOM inventory improve incident response.
A new vulnerability is disclosed. Your client asks: Are we affected?
How long would it take to produce a reliable answer? Five minutes, half a day, or until somebody finds the developer who set up the project two years ago?
Modern websites contain far more than code written by the current team. Frameworks, build tools, CMS extensions, SDKs, container base images, and transitive packages form a software supply chain. Without a record of what is actually running, a straightforward security question becomes an inventory exercise under pressure.
The myth: “We already run npm audit”
npm audit is useful. It checks dependencies against known vulnerability data and can provide actionable findings. But one command does not automatically answer the operational questions that matter:
- Which version is actually deployed in production?
- Is the affected package only used during development or shipped with the product?
- Are several applications using different lockfiles?
- Does the container include a vulnerable operating-system package too?
- Who decides whether a finding is exploitable in this application?
- Where is the reason for postponing an update documented?
A scanner provides signals. It does not replace an inventory or a decision process.
We have a lockfile. Is that enough?
A maintained lockfile matters because it records reproducible dependency versions. Blind spots still remain:
- The lockfile changed, but production is running an older build.
- Multiple package managers or workspaces are not captured consistently.
- Container and operating-system packages are missing.
- Runtime scripts, plugins, or CDN resources are not represented.
- An update removes one vulnerability while introducing a new transitive dependency.
The unit that ultimately matters is not merely the repository. It is the artifact that was actually released.
What a lightweight dependency inventory should do
Most website and SaaS teams do not need a heavyweight enterprise programme to improve visibility. A small automated process can cover the essentials:
- Commit lockfiles consistently. Builds should fail when the expected lockfile is missing or ignored.
- Make dependency changes visible in pull requests. GitHub Dependency Review can show newly introduced or changed dependencies and known vulnerabilities during review.
- Generate a machine-readable inventory for releases. A Software Bill of Materials, or SBOM, records components and relationships in a standardized format. CISA presents SBOMs as a building block for software supply-chain transparency.
- Connect the artifact to its inventory. Store the release ID, commit, image digest, and SBOM together.
- Prioritize findings in context. Severity alone is not enough. Consider reachability, public exposure, available exploits, and existing mitigations.
- Give exceptions an owner and an expiry date. “Update later” is not a process when nobody is responsible.
Quick check: is the project incident-ready?
Answer these questions for your most important website or application:
- Can you map the production version to a commit and build?
- Do you know which lockfile was used for that build?
- Are new dependencies reviewed explicitly?
- Do you inventory direct and transitive packages?
- Are container and system components included?
- Can you search for a CVE or package and identify affected deployments?
- Is there a named owner and response target?
- After remediation, do you verify that the vulnerable component is gone from the released artifact?
Several “no” answers do not necessarily mean you need another security product. They usually mean the connection between source, build, deployment, and ownership is incomplete.
What Website-Pflichtencheck would review
A technical supply-chain review should not stop at counting red alerts. It should examine lockfile discipline, update workflows, dependency review, reproducible builds, container base images, release traceability, scanner configuration, exception handling, and whether a finding can be followed all the way to production.
This is especially relevant after an agency change, in older projects, after a framework migration, or when several websites share internal packages and images.
The important question is not whether your software has dependencies. It is whether you can find and assess them quickly when it matters. If the answer still depends on memory and manual investigation, review the website and its delivery chain before the next critical advisory sets the schedule.