Periodic Review Checklist - Dependencies, SBOM and SCA
This checklist applies to all applications that use third-party libraries, SDKs, open-source packages or binary artefacts.
It serves as a binary, auditable verification instrument of the practical adoption of the prescriptions of Chapter 05 (DEP-001 to DEP-014), enabling:
- Continuous control of the application of SCA and SBOM practices
- Verification per project at key moments of the lifecycle
- Generation of operational indicators that can be aggregated by team or organisation
🗓️ It is recommended that it be reviewed at every release, dependency change or security exception, as indicated in
aplicacao-lifecycle.
📋 Verification Items
| Item | Verified? |
|---|---|
Is there an SBOM generated automatically per build (CycloneDX or SPDX), including transitive dependencies, versioned and linked to the artefact? (DEP-001) | ☐ |
Is the SBOM archived and accessible for audit, and signed with verified integrity (L3)? (DEP-001) | ☐ |
Is there an SCA scanner integrated into the CI/CD pipeline? (DEP-002) | ☐ |
Is there a documented severity policy that distinguishes findings that block from those that only alert? (DEP-002) | ☐ |
Does the pipeline block promotion in the face of unjustified critical/high findings, according to the level's threshold? (DEP-002) | ☐ |
Are the SCA reports accessible and associated with each version/release, with findings triaged by severity, exposure and fix? (DEP-002) | ☐ |
Is there a versioned lockfile without latest/*/unbounded range references, with integrity verifiable by hash? (DEP-003) | ☐ |
Are there no libraries copied manually outside the package manager, with periodic audit and enforcement in CI/CD (L2–L3)? (DEP-004) | ☐ |
Are only approved registries used in the build (allowlist enforced), with fallback to external registries controlled and audited? (DEP-005) | ☐ |
Is there a formal approval process for new dependencies (maintenance, licence, CVEs, popularity), with a traceable record (version, hash, owner, date)? (DEP-006) | ☐ |
| Is there automatic validation of licence compatibility against an organisational allowlist? | ☐ |
Is there an update policy with an SLA/TTL per CVE severity and an active bot that generates PRs with impact analysis, requiring human intervention for breaking changes? (DEP-007/DEP-008) | ☐ |
Is there traceability between findings, CVEs, exceptions and delivered artefacts (CVE → release)? (DEP-010) | ☐ |
| Are vulnerability exceptions formalised (justification, context of use, deadline, approver, compensation) and expired ones reviewed? | ☐ |
Is the inventory boundary (SBOM boundary) defined and documented, with detection of emergent dependencies (unexpected delta) and an approval process? (DEP-009) | ☐ |
| Is there detection of composition drift between the SBOM and the runtime, with an incident opened in the event of divergence (L3)? | ☐ |
Do systems with AI/ML components have an inventory of AI dependencies (models, datasets, MCP servers/tools, prompts) and an AI BOM per build (CycloneDX 1.6 ml-bom) linked to the SBOM? (DEP-011/DEP-012) | ☐ |
Do the AI models have a pinned version (no latest/aliases), appear on a list of approved providers with a risk classification, and does a major version change trigger a new eval suite and a review of the threat model? (DEP-013/DEP-014) | ☐ |
| Are the practices documented and traceable in the repository or pipeline? | ☐ |
🔄 Operational Integration
- This checklist can be integrated into pipelines, PR reviews, release gates or technical audits.
- The results can be tracked per commit, per release or per artefact.
- Each item must be validated with objective evidence (e.g.
.sbom.jsonfiles, reports, PR comments, issues).
⚠️ In the event of a negative answer, an approved formal exception must exist and be documented according to the chapter's exception model.
✅ Compliance and KPI
- Validation of this checklist makes it possible to declare compliance with Chapter 05 - Dependencies, SBOM and SCA.
- The count of affirmative answers can be used to measure the degree of adoption of the prescribed practices.
- This result can be aggregated by team, domain or organisation as an indicator of operational maturity.
📌 This operational mechanism is aligned with the model of continuous control and traceability defined in SbD-ToE.