Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
Which dependency artifacts prove supply-chain hygiene?
Updated
Four artifacts do most of the work: a committed lockfile per project, the update pull-request history, remediation records for known-vulnerable packages, and a licence inventory per release. Licence obligations are legal; update cadence is your own standard.
Dependency evidence map, last verified 10 September 2026 against OWASP software-composition-analysis guidance, NIST SP 800-218 (Secure Software Development Framework) practice PW.4 on reusing well-secured software, the CISA Known Exploited Vulnerabilities catalog, and ISO/IEC 27001:2022 Annex A 8.28 secure coding and 8.30 outsourced development, with GitHub and Renovate documentation for tool behaviour. Open-source licence terms are enforceable through copyright and contract law, which makes licence compliance a legal question for counsel rather than a hygiene preference. This page is not legal advice, does not determine YOUR obligations, does not start a clock, and does not file with an auditor.
What this page is, and what it is not
Audience: a developer, engineering leader, or compliance owner who needs third-party package risk to be auditable — both the security side and the licence side, which have different kinds of consequence.
This page is not legal advice. It does not determine YOUR obligations, does not decide which frameworks apply to your organisation, does not start a clock, and does not file anything with an auditor. Licence interpretation in particular is a legal question: whether a given licence's obligations are triggered by how you distribute or host software is for counsel, not for a scanner's category label. Last verified 10 September 2026.
The distinction that matters throughout: a missed security update is a risk you accepted, knowingly or not, and an auditor will treat it as a control question. A licence obligation you did not meet is potentially a breach of a copyright licence or a contract, with a different remedy and a different audience. Do not let one process quietly handle both.
- Lockfiles are the cheapest strong artifact in this whole cluster. A committed lockfile makes the dependency graph reproducible, which makes transitive analysis reliable and blast-radius questions answerable.
- Automated update pull requests only evidence a control if they are merged or dispositioned. Hundreds of open bot pull requests evidence that you were told and did not act.
- Transitive dependencies are where most exposure lives, and where declared-manifest tooling is weakest. Prefer resolution-based analysis.
- Vendored code, container base layers, and copied snippets are dependencies too, and are the ones most often missing from the inventory.
Dependency-hygiene-to-evidence map
Read the first column as the hygiene practice, the second as the artifact, the third as the control assertion, and the fourth as the common failure. Last verified 10 September 2026. Not legal advice.
| Hygiene practice | Evidence artifact | Control assertion it supports | Common failure |
|---|---|---|---|
| Pinned, reproducible dependency resolution | The committed lockfile per project, and the build configuration that installs from the lockfile rather than re-resolving | Builds are reproducible and the dependency set is known. NIST SP 800-218 PW.4; ISO/IEC 27001:2022 Annex A 8.28. | A lockfile in the repository that the build ignores, so what ships is not what the lockfile describes. |
| Complete dependency inventory | The resolved dependency list per project and release, including transitive dependencies, plus the record of vendored code and container base layers | You know what you depend on. Annex A 5.9 inventory of associated assets; AICPA TSC CC7.1. | Direct dependencies only, so an advisory in a transitive package is invisible until a customer asks. |
| Known-vulnerability detection | Dependency-alert or software-composition-analysis findings per project, with severity, status, and the source feed | Vulnerable components are detected. Annex A 8.8; AICPA TSC CC7.1; PCI DSS v4.0.1 Requirement 6.3.1 where in scope. | Scanning enabled on some repositories and not on the ones nobody owns. |
| Prioritised remediation | The disposition per finding — updated, mitigated, scheduled, or accepted — with the pull request or change that carried the fix | Findings are acted on deliberately. Annex A 8.8; see the vulnerability-management page in this cluster for the ranking method. | An alert queue with no dispositions, which evidences awareness without action. |
| Automated update flow | The update-tool configuration, the pull-request history it generated, the merge or close decision per pull request, and the reason where closed | Updates are proposed systematically and decided. Best practice; no framework named here requires automation. | A bot opening pull requests that nobody triages, so the artifact evidences a backlog. |
| Update cadence and staleness tracking | The record of how current dependencies are — per project age or drift measure — and the target you set for it | Dependency currency is managed rather than incidental. Best practice, and your own standard is what you are measured against. | A cadence stated in a policy that the data contradicts. |
| End-of-life and unmaintained component handling | The list of dependencies past upstream support or visibly unmaintained, and the decision per item — replace, fork with ownership, or accept with compensating measures | Unsupported components are known and owned. Annex A 8.8 and 8.30; AICPA TSC CC7.1. | Unmaintained packages treated as safe because no advisory exists for them, which conflates absence of reports with absence of risk. |
| Licence inventory per release | The licence for every component in the release, its category, and the record of any obligation triggered — notice, source availability, or attribution | Distribution obligations are known. This is a legal-compliance artifact, not a security one; see the section below. | A scanner's licence column accepted as a legal conclusion without counsel ever reviewing the categories. |
| Licence policy and exception handling | The written policy of which licence categories are permitted, restricted, or prohibited, its legal approval, and the exception records | Licence risk is governed. AICPA TSC CC9.2 and Annex A 5.31 legal, statutory, regulatory and contractual requirements. | An engineering-owned licence policy with no legal sign-off, which is a preference rather than a control. |
| Package source integrity | Registry configuration showing which registries are permitted, integrity hashes in the lockfile, and any internal proxy or mirror configuration | Packages come from expected sources. NIST SP 800-218 PW.4 and PO.3; Annex A 8.28. | Unrestricted registry access, leaving dependency-confusion and typosquat exposure with nothing to evidence against it. |
| Third-party and outsourced code | Terms with development suppliers covering component hygiene, and the evidence received from them | Outsourced development meets your standard. Annex A 8.30; AICPA TSC CC9.2. | Contractor-delivered code entering the estate with no inventory and no scanning. |
| Blast-radius answerability | Demonstrated ability to answer which services and releases include a named component version, including transitively | Impact assessment is possible during an advisory rather than after. Annex A 8.8; supports incident response under Annex A 5.26. | Knowing a package is affected without knowing where it ships, so remediation scope is guessed. |
Licence compliance is legal; update cadence is best practice
These two live in the same tooling and belong to different worlds. Open-source licences are enforceable instruments; a monthly update cadence is a standard you set for yourself. Treating both as engineering hygiene is how licence obligations get missed, and treating both as legal duties is how teams freeze. Last verified 10 September 2026. Not legal advice.
| Statement | Which kind of authority | What it does not mean |
|---|---|---|
| Open-source licence terms — for example copyleft source-availability and notice obligations, or attribution requirements in permissive licences. | Legal requirement — enforceable through copyright and contract law, independent of any security framework. Which obligations are triggered depends on how you distribute or host the software. | Does not mean a scanner's licence category is a legal conclusion. Whether an obligation is triggered by your distribution model is a question for counsel. |
| Contractual terms with customers about third-party components, open-source usage, or indemnities. | Legal requirement in the contractual sense, and often stricter than any framework. | Does not appear in your security control set unless someone puts it there. Check the contracts, not only the standards. |
| PCI DSS v4.0.1 Requirement 6.3.1 on identifying and ranking vulnerabilities, including in third-party and open-source components, and 6.3.3 on patching. | Legal requirement in the contractual sense, for entities in scope through card-brand and acquirer agreements. | Says nothing about licences, and does not apply outside cardholder-data scope. |
| ISO/IEC 27001:2022 Annex A 8.28 secure coding, 8.30 outsourced development, 5.31 legal and contractual requirements. | Certification requirement where you seek or hold certification. Annex A 5.31 is where licence obligations legitimately enter an ISMS. | Does not name a tool, a cadence, or a permitted-licence list. |
| NIST SP 800-218 PW.4 on acquiring and reusing well-secured software, and OWASP software-composition-analysis guidance. | Regulatory and standards guidance, and community best practice respectively. | Neither binds a commercial company by default, and neither prescribes an update frequency. |
| Update dependencies at least monthly, keep the automated update queue at zero untriaged items, and replace unmaintained components on a stated timeline. | Industry best practice, and a common pattern. Nothing above requires it. | Not a legal duty. But once written in your policy it becomes the standard you are audited against, so choose a number you will meet. |
| Have counsel approve the permitted-licence categories, and keep a per-release licence inventory with any triggered obligation recorded. | ShipReady Metrics recommendation. | Not required by any framework named here. It exists because licence findings surface at the worst possible time — during diligence or a customer negotiation. |
A sample automated-update evidence format
Automated update tooling produces plenty of activity and very little evidence unless you shape it. This is the format that answers an auditor's questions about it. Rows are illustrative format examples, not measurements of any real project. Last verified 10 September 2026. Not legal advice.
| Field or row | Example content | Why an auditor looks for it |
|---|---|---|
| Header — tooling and configuration | Update tool: platform-native dependency updates on 12 repositories, Renovate on 4. Configuration committed in each repository; grouping and schedule stated. Security updates enabled separately from version updates. | Shows the mechanism is configured deliberately and is version-controlled, not set by hand in a console. |
| Header — coverage | Repositories in scope: 16. Repositories with update automation enabled: 16, with the date each was enabled. | Coverage is the first question. A tool on most repositories is a partial control. |
| Row — security update merged | Pull request reference, package and version change, advisory identifier, KEV listed status, opened date, merged date, reviewer, the deploy that carried it. | Traces detection to production, which is what closes a remediation sample. |
| Row — security update closed without merge | Pull request reference, reason recorded: package not reachable in the affected code path; compensating analysis referenced; approver named; revisit date. | A closed alert with a reason is a decision. A closed alert with no reason looks like suppression. |
| Row — version update batched | Grouped pull request reference, packages included, test results, merged date. Batching policy stated in the configuration. | Shows routine currency work happening, and that batching is a policy rather than an accident. |
| Row — blocked update | Package, target version, blocker recorded: breaking change requiring an interface migration; owner named; scheduled release; interim mitigation. | Blocked with an owner and a plan is managed; blocked silently is aging risk. |
| Footer — queue state | Open update pull requests at period end: 7, all opened within the last 14 days, none security-related. Untriaged items older than 30 days: 0. | Distinguishes a working queue from a graveyard, which is the difference between a control and a backlog. |
| Footer — licence check | Licence scan run per release; categories outside the approved list in the period: 1, escalated to counsel, resolved by replacing the component. Approved-category list version referenced. | Shows the licence side is handled by the people who can decide it, and that escalation actually happens. |
Checklist
A question list for the dependency side of your evidence set. Not a determination that any framework applies to you. Last verified 10 September 2026. Not legal advice.
- Does every project commit a lockfile, and does the build install from it rather than re-resolving?
- Can we produce the resolved dependency list, including transitive dependencies, for a given release?
- Are vendored code, container base layers, and copied snippets in the inventory?
- Is dependency scanning enabled on every repository in scope, including the ones without a clear owner?
- Does every finding have a disposition — updated, mitigated, scheduled, or accepted with an approver?
- Is our automated update queue triaged, and can we show the age of the oldest untriaged item?
- Do we track dependency staleness against a stated target, and does the data match the policy?
- Do we know which dependencies are past upstream support, and what the decision is for each?
- Has counsel approved our permitted-licence categories, and is there a per-release licence inventory?
- Are package registries restricted, and are integrity hashes present in the lockfile?
- Do supplier and contractor development terms cover component hygiene, and have we received anything under them?
- Can we answer which releases contain a named component version, transitively, without a research project?
What to do now
Ordered so that the cheapest strong artifacts land first. None of these steps is a legal determination, and none files anything with an auditor.
- Commit lockfiles everywhere and make the build install from them. It is a small change that makes every downstream analysis on this page reliable.
- Enable dependency scanning on every repository in scope, then find the repositories nobody claimed and give them owners.
- Triage the automated update queue to zero untriaged items once, and then keep it there. A working queue is evidence; a graveyard is a finding.
- Require a recorded reason on every closed security update pull request, so closure is a decision rather than a dismissal.
- Get counsel to approve the permitted-licence categories, then produce a per-release licence inventory and escalate exceptions to them rather than resolving them in engineering.
- Add end-of-life and unmaintained-component review to the same cadence, since no advisory will ever tell you a package has been abandoned.
- Restrict registries and verify integrity hashes, which closes dependency-confusion exposure that no alert feed will report.
- Re-verify OWASP, NIST SSDF, and your tooling documentation annually, and record the date. Ours says 10 September 2026.
Where this shows up in ShipReady Metrics
Only shipped behaviour is described here. This product does not update your dependencies, does not open update pull requests, does not make licence determinations, and does not file anything with an auditor.
The GitHub App is read-only and ingests Dependabot alerts, code-scanning alerts, and secret-scanning alerts as findings; GitLab ingest covers security findings the same way. Findings are deduplicated across sources and ranked using CISA KEV membership, EPSS, and CVSS.
Blast-radius search runs over captured dependencies, including transitive npm dependencies where a lockfile was fetched. That is the practical answer to which captured services include an affected package — and it depends on the lockfile existing, which is why the first recommendation above matters.
If you already have a session: signed-in app → Compliance holds evidence collection for control-mapped artifacts across starter control subsets, and evidence review, where a named human accepting a manual row renders it met and rejecting it renders it a gap, with a timestamp. Licence inventories and supplier terms are manual rows. That overlay is a timestamped compliance artifact — not a forensic chain of custody, not a downloadable evidence binder, and not an auditor's opinion.
Primary sources (last verified 10 September 2026)
Each source is labelled by the kind of authority it carries.
Open-source licence terms are legal instruments enforceable through copyright and contract law. NIST SP 800-218 practice PW.4 and OWASP software-composition-analysis guidance are standards guidance and community best practice. The CISA Known Exploited Vulnerabilities catalog is published guidance, binding only on US federal civilian executive branch agencies through Binding Operational Directive 22-01. ISO/IEC 27001:2022 Annex A 5.9, 5.31, 8.8, 8.28 and 8.30 are certification requirements. AICPA Trust Services Criteria CC7.1 and CC9.2 are attestation criteria. PCI DSS v4.0.1 Requirement 6.3 binds entities in scope through contract. GitHub and Renovate documentation are the authority for those tools' behaviour. Not a complete list, and not legal advice.
The SBOM page in this cluster covers the per-release inventory artifact, the vulnerability-management page covers prioritisation and remediation records, and the GitHub and GitLab pages cover the platform surfaces that produce this evidence.
Frequently asked questions
Is this legal advice?
No — and the licence half of this page is the part where that matters most. Whether a given open-source licence obligation is triggered by how you distribute or host your software is a legal question for counsel, not a scanner category. Whether SOC 2, ISO/IEC 27001, PCI DSS, or any statute applies to your organisation is likewise for counsel and your contracts. This page does not determine YOUR obligations.
Are hundreds of open bot pull requests a problem for an audit?
Yes, because they are evidence that you were told about updates and did not act. An untriaged queue turns your own tooling into the record of an unmanaged backlog. Triage to zero untriaged items once, require a recorded reason on every closed security update, and the same tooling becomes strong evidence of a working control.
Do we need a formal dependency update cadence?
No framework named on this page requires one. Monthly updates and a zero untriaged queue are industry best practice, not a mandate. The important part is that whatever cadence you write into your policy is the standard you will be tested against — so set one you can sustain rather than one that sounds impressive.
Is a licence scanner's output enough for licence compliance?
No. A scanner tells you which licences are present and puts them in categories it chose. Whether an obligation is triggered — source availability, notice, attribution, or a contractual restriction with a customer — depends on your distribution model and your contracts, and that is a legal judgement. Have counsel approve the permitted categories and escalate exceptions to them.
How does ShipReady Metrics help with transitive dependencies?
Blast-radius search runs over captured dependencies, including transitive npm dependencies where a lockfile was fetched, so you can find which captured services include an affected package. Findings from Dependabot, code scanning, and secret scanning are ingested read-only, deduplicated across sources, and ranked with KEV, EPSS, and CVSS. It does not update packages or open pull requests.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.