Skip to content

Update VM-05 to split dependency remediation enforcement into 4 areas #553

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Satarupa22-SD wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Update VM-05 to split dependency remediation enforcement into 4 areas #553

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
712857d
Update VM-05 to split dependency remediation enforcement into 4 areas
Satarupa22-SD Sep 3, 2026
d8bf79e
link pr
Satarupa22-SD Sep 3, 2026
34c78a8
update control-ids
Satarupa22-SD Sep 3, 2026
dbf4d81
Merge remote-tracking branch 'upstream/main' into OSPS-VM-05.03
Satarupa22-SD Oct 2, 2026
ea646ab
update OSPS-VM-05.03
Satarupa22-SD Oct 2, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 37 additions & 8 deletions baseline/OSPS-VM.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -159,18 +159,47 @@ controls:
that verify compliance with that policy prior to release.
- id: OSPS-VM-05.03
text: |
All changes to the project's codebase MUST be
automatically evaluated against a documented policy for malicious
dependencies and known vulnerabilities in dependencies, then blocked
in the event of violations, except when declared and suppressed as
non-exploitable.
Retired in https://github.com/ossf/security-baseline/pull/553
applicability:
- maturity-3
state: Retired
- id: OSPS-VM-05.06

@evankanderson evankanderson Oct 2, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wish that we hadn't put the VM-05.X requirements out of order in this YAML file. 😦

text: |
All changes to the project's codebase MUST be automatically
evaluated against a documented policy for malicious dependencies.
applicability:
- maturity-3
recommendation: |
Create a status check in the project's version control system that
runs a Software Composition Analysis tool on all changes
to the codebase. Require that the status check passes before changes
can be merged.
runs a Software Composition Analysis tool on all changes to the
codebase to detect malicious dependencies, and configure it to
evaluate changes against the project's documented policy.
- id: OSPS-VM-05.07
Comment thread
funnelfiasco marked this conversation as resolved.
text: |
All changes to the project's codebase MUST be automatically
evaluated against a documented policy for known vulnerabilities in
dependencies.
applicability:
- maturity-3
recommendation: |
Create a status check in the project's version control system that
runs a Software Composition Analysis tool on all changes to the
codebase to detect known vulnerabilities in dependencies, and
configure it to evaluate changes against the project's documented
policy.
- id: OSPS-VM-05.08
Comment thread
funnelfiasco marked this conversation as resolved.
text: |
Changes to the codebase MUST be blocked when they violate the
documented policy for malicious dependencies or known
vulnerabilities.
Comment on lines +192 to +194

@evankanderson evankanderson Sep 4, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure how I feel about breaking the previous (admittedly wordy) control up into three, where the three are:

  1. Block malicious dependencies
  2. Block vulnerable dependencies
  3. The blocking must be automatic and enforced

I can see separating 1 and 2 (though I could also see arguing that malicious dependencies are de-facto "vulnerable"), but splitting this into 3 or 4 seems too much.

@eddie-knight eddie-knight Sep 8, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this remains true to what it's always been. Roughly...

  1. Evaluate using a policy about code that introduces risk
  2. Evaluate using a policy about code that introduces an attack
  3. Block policy violations

@evankanderson evankanderson Sep 23, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels to me like "Block policy violations" should just be part of the control, unless we're planning to put the "define a policy" and "enforce a policy" at different baseline conformance levels.

@Satarupa22-SD Satarupa22-SD Oct 2, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have split this into three for now, but in case there should be only two controls, then it can be rewritten as

All changes to the project's codebase MUST be automatically evaluated against a documented policy for malicious dependencies, then blocked in the event of violations, except when the findings are declared and suppressed as non-exploitable.

Comment on lines +192 to +194

@evankanderson evankanderson Oct 2, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the purpose of this change if all of these requirements apply at maturity level 3.

It seems likely that the same tool will be used to flag the introduction of vulnerability-introducing dependencies, so it seems like the implementation of VM-05.06 and VM-05.07 is likely to be evaluated by the same check.

Similarly, I'm not sure that defining "automatically checked" and "blocked by an automatic check" as two different policies provides substantial additional clarity.

If splitting this introduced meaningful differences in the checks performed at a given level, I'd be 100% in favor. Right now, it feels like we're introducing three checkboxes where one could do, so I'd like to understand why there's a benefit to that extra checklist verbosity. (Yes, I fully grant that the VM-05.03 text is tortured, and should be taken out and replaced. But it's not clear that the solution is adding extra boxes to check at the same time.)

@Satarupa22-SD Satarupa22-SD Oct 15, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A project can run an SCA tool in report-only mode, where dependencies are evaluated but nothing is blocked. Again, another project might enforce a required status check for only one of the two policies, for example, blocking known vulnerabilities but not malicious dependencies. With separate controls, an assessor can report exactly which of these is missing. A single combined control can only return one pass or fail. So splitting them would benefit the assessment side, even if most projects will satisfy both with the same tool.

applicability:
- maturity-3
recommendation: |
Configure the project's version control system to require that the
Software Composition Analysis status checks pass before changes can
be merged. The policy may allow findings to be suppressed (for
example, by documenting them in a VEX statement) when they are
determined to be non-exploitable.

- id: OSPS-VM-06
title: |
Expand Down
Loading