feat: add OSPS security baseline rule types for GitLab#401
feat: add OSPS security baseline rule types for GitLab#401intelligent-ears wants to merge 2 commits into
Conversation
|
|
evankanderson
left a comment
evankanderson
left a comment
There was a problem hiding this comment.
A few comments; I'd also like to wait for #402, even though these don't have tests.
My main concern is that it seems like we're needing to duplicate identical rules for github and gitlab. Maybe the context.provider should be a list of supported_provider_types that the provider needs to implement for this rule?
| severity: | ||
| value: high | ||
| context: | ||
| provider: gitlab |
There was a problem hiding this comment.
Is this the same rule as for github, but with the provider changed?
I'm trying to think if there's a better way to express this.
There was a problem hiding this comment.
Yes, exactly — it's identical except for context.provider: gitlab. The Rego logic, ingest type, and everything else is the same. I think the right long-term fix is to allow context.provider to accept a list (e.g. provider: [github, gitlab]) so provider-agnostic rules don't need to be duplicated. I can open a separate issue in minder to track that, or handle it here if you'd prefer.
There was a problem hiding this comment.
Open an issue in Minder, and link to this PR for an example of how the current behavior is not great.
| import future.keywords.every | ||
| import future.keywords.if |
There was a problem hiding this comment.
Pefer:
| import future.keywords.every | |
| import future.keywords.if | |
| import rego.v1 |
See also #398
| allow if { | ||
| files := file.ls_glob("./CONTRIBUTING/*") | ||
|
|
||
| some name | ||
| content := file.read(files[name]) | ||
| "" != content | ||
| } |
There was a problem hiding this comment.
Why is this duplicated with 34-40?
| allow if { | ||
| files := file.ls_glob("./LICENSE/*") | ||
|
|
||
| some name | ||
| content := file.read(files[name]) | ||
| "" != content | ||
| } |
There was a problem hiding this comment.
Weird, this also duplicates 34-40
| import future.keywords.every | ||
| import future.keywords.if | ||
|
|
There was a problem hiding this comment.
| import future.keywords.every | |
| import future.keywords.if | |
| import rego.v1 | |
intelligent-ears
force-pushed
the
feat/osps-baseline-gitlab-rules
branch
from
133f02e to
3baebb3
Compare
Port 6 git-ingest based OSPS level-1 rules from GitHub to GitLab. These rules use git clone ingest (no GitHub API calls) and work identically with GitLab repositories. Rules ported: - osps-br-03-02: Deliver releases via encrypted channels - osps-gv-03-01: Enforce CONTRIBUTING file presence - osps-le-03-01: LICENSE or COPYING files are available - osps-qa-02-01: Source code contains direct dependency list - osps-qa-05-01: No generated executable artifacts in VCS - osps-qa-05-02: No unreviewable binary artifacts in VCS Part of mindersec/minder#6435
intelligent-ears
force-pushed
the
feat/osps-baseline-gitlab-rules
branch
from
cc19ea6 to
e079d56
Compare
3 participants
Port 6 OSPS Security Baseline level-1 rules to GitLab
Adds GitLab versions of 6 OSPS Baseline level-1 rules that use git ingest (clone-based file checks with no GitHub API calls). These rules work identically with GitLab repositories — the only change from the GitHub versions is context: provider: gitlab.
Rules added:
osps-br-03-02: Deliver releases via encrypted channels
osps-gv-03-01: Enforce CONTRIBUTING file presence
osps-le-03-01: LICENSE or COPYING files are available
osps-qa-02-01: Source code contains direct dependency list
osps-qa-05-01: No generated executable artifacts in VCS
osps-qa-05-02: No unreviewable binary artifacts in VCS
Part of the GitLab provider coverage work tracked in mindersec/minder#6435.
The remaining 15 level-1 rules use GitHub REST API endpoints and will need separate GitLab API equivalents in follow-up PRs.