alpha-omega-security/scrutineer

Scrutineer imports SARIF through github.com/git-pkgs/sarif, but its repository findings endpoint exports JSONL or a sharing bundle. Add format=sarif to GET /api/v1/repositories/{id}/findings so operators can pass findings to other security tools, including OSS-CRS as bug candidates. Use the existing dependency's types, constructors, Validate and Dump. The pinned dependency already provides these APIs. The work belongs in Scrutineer's finding-to-SARIF mapping and export handler. Preserve repository and observed commit provenance, finding identity, CWE, severity, locations and supporting evidence. Findings from different commits must retain the correct revision rather than all being attributed to the repository's current HEAD. Honour the endpoint's existing finding selection options. Keep disclosure correspondence and recipient details out of the SARIF report. Keep candidate findings and verification evidence distinguishable; exporting a finding must not imply that it has been verified.

As of yesterday, GitHub have released a new structured As a starting point, all repositories now use the structure: Now, by default, reporters must fill in four required fields: summary, details, proof of concept (at least 150 characters), and impact. But repositories/orgs are also free to customise this. We should: Ensure our disclosure generation has a reasonable mapping for the new defaults I feel this is probably good right now, so needs no changes Detect if a repo's .github/VULNERABILITY_REPORT.yml or the org's .github repo has a .github/VULNERABILITY_REPORT.yml, and if so, customise the output to fit within that

Extend the repository-mode routing introduced by the package manager audit to other kinds of software. Triage should detect the implemented behavior from source evidence and enqueue focused audits alongside the normal pipeline. The first targets are: Web applications and APIs: sessions, tenant boundaries, browser origins, uploads, and business workflows. Use OWASP ASVS as a verification reference and reuse existing focused audits where they fit. Embedded and IoT software: firmware updates, rollback protection, provisioning, device credentials, debug interfaces, and physical-access assumptions. OWASP ISVS is a starting point. Record guarantees that need hardware or deployment evidence as unresolved assumptions. Other candidates include build systems and developer tools, parsers and file processors, and mobile applications. Their audits could cover untrusted workspaces and build caches, hostile file formats and resource limits, or platform permissions and local storage respectively. OW

Hardened scans already verify that a public IPv4 connection is blocked and the egress proxy remains reachable on runtimes requiring those probes. Existing Docker and Podman integration tests cover parts of the sidecar boundary. Broaden this coverage to establish what hostile code can actually reach from a scan container. Add runtime integration tests covering: Direct connections with proxy variables removed, including IPv6 where available. DNS requests over UDP and TCP, including attempts to send data to an unauthorized resolver or through a runtime-provided resolver. Host services, cloud metadata addresses, and sibling scan containers. Forged HTTP Host or authority values and CONNECT requests attempting to reach operator routes or unauthorized destinations. Proxy failure, cleanup after cancellation, and isolation between concurrent scans with different permissions. Use controlled destinations and verify whether requests arrive, so an unavailable public endpoint cannot produce a fals

Summary The subproject detail page's Export findings link points to the skill callback API at /api/repositories/{id}/findings?sub_path=.... An ordinary browser request has no running-scan bearer token, so clicking the link returns HTTP 401 instead of exporting findings. Affected Code internal/web/templates/subproject_show.html:21: export link. internal/web/api.go: apiAuth. internal/web/api_export.go: repository findings export and applyFindingFilters. Cause and Impact The /api/ skill routes require bearer authentication associated with a running scan. The intended browser export route is /api/v1/repositories/{id}/findings, which uses the host-only operator boundary and does not require a scan bearer token. That route already supports sub_path filtering. The template uses the wrong route prefix, making the visible download action fail for normal browser use. Verified Reproduction Open a repository's subproject detail page at /repositories/{id}/subprojects/{sub}. Follow its Export fin