Acquire, create and maintain well-secured software components rather than reimplementing them, and verify throughout their life cycle that acquired components comply with the organization’s requirements.
Partly covered — 83%. The controls beneath it are covered in some of the places your profile required them and not in others.
No single control answers this requirement outright, so the 3 partial mappings your profile required are averaged.
Closing the 9 scopes listed here would move your overall coverage by 6.4 percentage points — exactly, over the same denominator the headline uses.
Counted toward this requirement These produced the number above.
Dependency Composition Scan ● 18 of 18 scopes
Partial mapping · high confidence
What it is Third-party dependencies of the application are resolved and checked against known vulnerability data on every build. Why it matters Most of the code being shipped was not written by the team, and a dependency becomes vulnerable long after it was chosen. Why it maps PW.4.4 requires acquired third-party components to be verified against organizational requirements throughout their life cycle, and names composition analysis as a way to do it.
Covered everywhere your profile required it.
Vulnerable Dependency Gate ◐ 9 of 18 scopes
Partial mapping · high confidence
What it is A build that pulls in a dependency with a critical, fixable vulnerability is stopped rather than shipped. Why it matters Knowing about a critical, fixable dependency vulnerability and shipping anyway is the ordinary path by which known issues reach production. Why it maps Verification under PW.4.4 has to have a consequence, or a component that fails it is still reused.
What would close it
The required scopes nothing covers today:
Environment Technology Phase Control point Development Java Release Release Gate Development Spring Boot Release Release Gate Development React Release
Automated Dependency Updates ● 9 of 9 scopes
Partial mapping · medium confidence
What it is Outdated or vulnerable dependencies are proposed for upgrade automatically so that remediation does not depend on someone noticing. Why it matters Manual upgrades happen when somebody has time, which is why dependencies fall years behind and a single upgrade turns into a project. Why it maps PW.4.1 says acquire *and maintain*; an unmaintained dependency stops being the well-secured component it was when it was chosen.
Covered everywhere your profile required it.
Your profile never required these The catalog maps them to this requirement; your baseline did not ask for them. They are listed, not scored — nothing was demanded of them, so nothing about them has failed.
Approved Base Image Baseline not required
Partial mapping · medium confidence
Why it maps A maintained approved base image is the container-layer form of the reuse PW.4.1 asks for: the security posture is checked once, centrally, instead of per team.
Binary Composition Analysis not required
Partial mapping · medium confidence
Why it maps PW.4.4 covers components no manifest declares; only analysis of the delivered binary finds those.
Supporting only, never counted A control that merely helps cannot be the reason something is called satisfied. Listed so you can see the whole picture, never counted.
Artifact Malware Scan not required
Supporting · medium confidence
Why it maps Malicious content in an acquired artifact is the failure mode PW.4.4 verification exists to catch, but a clean scan is not compliance with the requirements.
License Policy Enforcement not required
Supporting · low confidence
Why it maps PW.4.4 speaks of the requirements "as defined by the organization", which can include license policy; the practice’s own subject is security, so this reading is arguable.
