Skip to content
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

Jump to bottom

added two new criteria #35

Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open

added two new criteria #35

Changes from 8 commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
af4f25c
Update baseline.yaml
SecurityCRob Oct 18, 2024
c87e9ac
Update baseline.yaml
SecurityCRob Oct 18, 2024
20268bf
Merge pull request #1 from SecurityCRob/SecurityCRob-patch-1
SecurityCRob Oct 18, 2024
e6fb13b
Merge branch 'main' into SecurityCRob-patch-2
SecurityCRob Oct 18, 2024
2d442ee
Merge pull request #2 from SecurityCRob/SecurityCRob-patch-2
SecurityCRob Oct 18, 2024
b81642c
Update baseline.yaml
SecurityCRob Oct 18, 2024
d2d586c
Update baseline.yaml
SecurityCRob Oct 18, 2024
9ccdb08
Update baseline.yaml
SecurityCRob Nov 7, 2024
c0d5f1f
Update baseline.yaml
SecurityCRob Nov 14, 2024
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
56 changes: 56 additions & 0 deletions baseline.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -720,6 +720,62 @@ criteria:
in a separate repository and fetched during
a specific well-documented pipeline step.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe: # TODO
- id: OSPS-53
Copy link

Choose a reason for hiding this comment

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

I disagree with this one as worded fairly strongly.

I would reword it "cryptographically attested" -- We've seen multiple issues with just signing a piece of software.

Copy link
Contributor

Choose a reason for hiding this comment

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

@mlieberman85 If the desire is for more than signing— should we split this into Lv2 signature, and Lv3 for more complete attestation?

Copy link

Choose a reason for hiding this comment

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

I think that's reasonable. I think we should also be clear what just blanket "signing" should be interpreted as. Since people sign a lot of stuff for a lot of reasons, which is why folks have been moving to attestations so it's clear what the intent of the signing is.

Copy link
Member

Choose a reason for hiding this comment

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

I think the first level should be plain signing with published singer identities. It's way easier to implement plain signing and it gets us initial integrity guarantees.

maturity_level: 2
category: Build & Release
criteria: |
All released software assets MUST be signed
SecurityCRob marked this conversation as resolved.
Show resolved Hide resolved
with a cryptographic signature.
objective: |
Provide users with a mechanism to verify the
authenticity and integrity of released
software assets, reducing the risk of
tampering or unauthorized modifications.
implementation: |
Sign all released software assets at build
time with a cryptographic signature or attestations, such
as GPG or PGP signature, Sigstore signatures, SLSA provenance, or SLSA VSAs.

Provide clear documentation for users on how they can verify the signature
and what a valid signature or attestation indicates (e.g.
"it came from our CI/CD system",
"one of our project maintainers built the software", "it was built from the
indicated source repo with the indicated builder", "it meets SLSA level 3").

SecurityCRob marked this conversation as resolved.
Show resolved Hide resolved
It is recommended that this signature is
generated as part of the build and release
pipeline to ensure that it is consistent and
automated.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe:
- releasesAreSigned
- id: OSPS-54
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd suggest splitting this out into a separate PR, since it seems less controversial than the other one.

maturity_level: 3
category: Quality
criteria: |
All proposed changes to the project's
codebase must be automatically evaluated
against a documented policy for known
vulnerabilities and blocked in the
event of violations.
objective: |
Identify and address defects and security weaknesses
in the project's codebase early in the
development process, reducing the risk of
shipping insecure software.
implementation: |
Create a status check in the project's
version control system that runs a Static
Application Security Testing (SAST) tool on
all changes to the codebase. Require that the
status check passes before changes can be
merged.
control_mappings: # TODO
security_insights_value: # TODO
scorecard_probe: # sastToolRunsOnAllCommits
- id: OSPS-70
maturity_level: 3
category: Access Control
Expand Down