Organisational Policies - Dependencies, SBOM and SCA

The effective adoption of Chapter 05 - Dependencies, SBOM and SCA - requires the existence of formal organisational policies that regulate and support the secure management of third-party libraries, software composition analysis and the use of SBOMs.

---

📌 Fundamental note

⚠️ The technical practices described in this chapter (inventory, SCA analysis, SBOM integration, origin registries, exception management) must be legitimised by approved organisational policies.

These policies:

• Make the management of dependencies and external artefacts mandatory and auditable;
• Allow decisions on updating, blocking or accepting risks to follow defined and consistent criteria;
• Are a mandatory reference in build, CI/CD, vulnerability management and audit processes.

🧩 This chapter operationalises the formal policies on dependencies and external components. The policy defines, the chapter executes.

📎 The existence of these policies is explicitly recommended by frameworks such as NIST SSDF, OWASP SAMM and SLSA .

---

🧾 Recommended policies

Policy Name	Mandatory?	Application	Summary of the required content
Dependency and Library Management Policy	✅ Yes	All projects with third-party code	Rules for the use, approval, versioning, updating and blocking of dependencies.
SBOM Integration and Management Policy	✅ Yes	Build, release and audit pipelines	Required format (CycloneDX/SPDX), generation frequency, mandatory artefacts and retention.
Policy on Vulnerability Assessment in Third-Party Components (SCA)	✅ Yes	Projects delivering to production	Mandatory SCA analysis, severity criteria, response cycle and exception register.
Repositories and Origin Registries Policy	⚠️ Optional	CI/CD, build agents, execution environments	List of authorised registries, internal mirrors, fallback and caching policies.
Policy on the Justification of Accepted Vulnerabilities	✅ Yes	When a CVE is accepted without an immediate patch	Requirements for justifying exceptions, formal approval, periodic revalidation.
Continuous Dependency Update Policy	⚠️ Optional	Projects with short, continuous cycles	Update frequency, use of automated tools, traceability of changes.

---

📋 Suggested structure of each policy

Each organisational policy must contain, at a minimum:

• Objective and scope of the policy;
• Scope of application: who, where and when it applies;
• Mandatory rules and criteria (e.g. when to analyse, how to approve a dependency, SBOM format);
• Roles and responsibilities (security, product, dev, operations, CI/CD);
• Requirement for documentation and traceability;
• Review frequency of the policy itself (e.g. annual);
• Requirement for traceability between policy, practice and technical evidence (e.g. SBOM ↔ build ↔ release ↔ findings link).

---

✅ Final recommendations

• These policies must be approved by the security and development areas;
• They must be documented, disseminated and accessible to all technical teams;
• Their existence is an essential condition for guaranteeing formal control of the dependency chain and the integrity of builds;
• Their application must be automated whenever possible, integrated into pipelines and release validations.

📌 Examples of policy templates may be included in complementary 60-*.md files in future versions.