Build Security Scanning
Patch release builds should be checked for build-tool, dependency, and pipeline-injection risks before publication.
Structured Requirements
Patch providers should run build-security scanning appropriate to the package ecosystem before publishing an official patched artifact.
| Check | Severity | Evidence |
|---|---|---|
|
REL-008.CHECK-001 Build-security scan evidence is present |
observe | build_security_scan_tool, scan_scope, scan_result |
Build-security evidence should identify unresolved high-risk findings or explain why the selected tooling is not applicable to the patched project.
| Check | Severity | Evidence |
|---|---|---|
|
REL-008.CHECK-002 Build-security findings are dispositioned |
observe | unresolved_findings, finding_disposition, not_applicable_rationale |
Requirement
Patch providers SHOULD run build-security scanning appropriate to the package ecosystem before publishing an official patched artifact.
Build-security evidence SHOULD identify unresolved high-risk findings or explain why the selected tooling is not applicable to the patched project.
Rationale
Build files, dependency resolution, and release pipelines can become part of the attack surface for patched artifacts. The working group should observe whether implementers can consistently scan for risks such as unsafe build plugins, dependency confusion exposure, script injection, tampered wrappers, unexpected network fetches, and publish-time credential leakage.
This is not proposed as a blocking SP-0.1.0 requirement because tooling differs by ecosystem and repository age. The first step should be to collect evidence about which checks are practical across representative patch repositories, then decide whether a narrower enforceable subset belongs in OSERA-SP-0.2.0.
Scanner expectations should be informed by the member tooling survey in finos-osera/operations-taskforce#6, with responses requested by September 4, 2026.
Observe-mode evidence
Observe-mode evidence SHOULD include:
- patched coordinate and source tag;
- build system and package ecosystem;
- build-security scan tool or manual review method;
- scan scope, including build files, wrappers, plugins, dependency resolution, and publication pipeline where applicable;
- scan result;
- unresolved high-risk findings;
- rationale when scanning is not applicable or no ecosystem-appropriate scanner is available.