-
Notifications
You must be signed in to change notification settings - Fork 4
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.
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
added two new criteria #35
base: main
Are you sure you want to change the base?
Changes from 5 commits
af4f25c
c87e9ac
20268bf
e6fb13b
2d442ee
b81642c
d2d586c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -720,6 +720,55 @@ 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 | ||
maturity_level: 2 | ||
category: Build & Release | ||
criteria: | | ||
All released software assets MUST be signed | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is not nearly rigorous enough. Anyone can sign anything. The goal here is to cryptographically tie some element of the software (e.g. it's build) to the approved maintainers of that software. As written it's way too weak. |
||
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, such | ||
as a GPG or PGP signature. | ||
SecurityCRob marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
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 | ||
maturity_level: 3 | ||
category: Quality | ||
criteria: | | ||
All changes to the project's codebase MUST | ||
require a passing status check from a | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is too vague. Who decides what the passing status check is? This is why I like SSDF's PW7 and PW8
SSDF instead of explicitly calling out SAST states it a bit more broadly and also highlights that it's up to the organization or system's security needs to determine what to do when an issue arises. Other docs like NIST 800-53 include similar but a bit more specific wording, e.g.
I would push for us to use this sort of wording. As written it's:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For PW 7.2 SSDF does call out the use of static analysis tools and is somewhat specific about how to handle the results "Example 4: Use a static analysis tool to automatically check code for vulnerabilities and compliance with the organization’s secure coding standards with a human reviewing the issues reported by the tool and remediating them as necessary." I'd agree that we should probably call out specific examples of what these tools are. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Agreed that this needs to be defined. We have a lexicon definition of SCA, but currently lacking one for SAST.
Our lexicon segments the codebase from the documentation (We can also improve this if needed). - term: Codebase
definition: |
The collection of source code and related
assets that make up the project. The codebase
includes all files necessary to build and
test the software. Lives in the repository,
sometimes alongside documentation and CI/CD
pipelines. The contents of the codebase are
the primary deliverable in a release. |
||
Static Application Security Testing (SAST) | ||
tool. | ||
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 | ||
|
There was a problem hiding this comment.
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.