oss-analyzer

100 % Open-Source-Code-Analyse-Suite (Sicherheit & Compliance) für GitLab CI und GitHub Actions — SCA, SAST, Secrets und Lizenzen, gesteuert durch eine einzige versionierte Policy. Polyglotte Repositories (Go, Rust, Java/JVM, Python, JS/TS, C/C++). Kein SaaS, kein Code wird an Dritte gesendet.

Erste Schritte

oss-analyzer prüft ein Repository in CI auf seine Sicherheit und Compliance: Es führt die Scanner aus, wendet eine versionierte Policy an und liefert ein einziges Urteil, mit einem HTML-Dashboard und Merge-Request-Berichten.

flowchart LR
    repo["Your repository"]
    subgraph checks["Scanners: they collect, never block"]
        deps["Dependencies<br/>Syft SBOM<br/>Grype, OSV-Scanner"]
        licenses["Licenses<br/>license gate on the SBOM<br/>policy-licenses.yml"]
        code["Code<br/>Semgrep<br/>policy-semgrep.yml"]
        secrets["Secrets<br/>Gitleaks, whole git history<br/>policy-gitleaks.toml"]
        iac["Dockerfiles, IaC<br/>Trivy"]
        headers["SPDX headers<br/>REUSE"]
    end
    policy{{"Policy<br/>thresholds, modes, exceptions<br/>policy-global.yml"}}
    verdict(["One verdict: pass or block<br/>dashboard, merge request reports"])

    repo --> deps & licenses & code & secrets & iac & headers --> policy --> verdict

Die policy-*-Dateien sind Ihre Einstellungen in Ihrem security/-Ordner: jede davon ist optional und ergänzt die Standardwerte von oss-analyzer (siehe Anpassen von oss-analyzer).

Jeder Befund landet in einem Dashboard, hier an einem bewusst verwundbaren Demo-Projekt (590 Befunde, davon 333 blockierend):

Drei Möglichkeiten, es auszuführen, mit derselben Policy und demselben Bericht:

GitLab CI/CD-Komponente

include:
  - component: gitlab.com/thalesgroup/oss-analyzer/[email protected]

Das ist alles, auf gitlab.com: Die Komponente wird in ihrem CI/CD-Katalog von gitlab.com/thalesgroup/oss-analyzer veröffentlicht, einer schreibgeschützten Kopie dieses Repositorys. Auf einer selbstverwalteten Instanz, die nur eigene Projekte einbinden kann, spiegeln Sie dieses Projekt dorthin und binden es über seinen Pfad auf Ihrer Instanz ein; sein Image verbleibt auf registry.gitlab.com/thalesgroup/oss-analyzer (OSA_IMAGE_REPOSITORY), getaggt mit dem Commit-SHA der Komponente. Die Analyse läuft in der test-Stage bei Merge Requests, im Standard-Branch, bei Zeitplänen und Tags; osa_report_aggregate ist der einzige Job, der blockieren kann. Das Dashboard ist als OSS security dashboard im MR-Pipeline-Widget verlinkt, und der Reports-Tab des MR zeigt die Funde an (Security scan, Code Quality).

• Images stammen aus ihren öffentlichen Registries (Docker Hub, ghcr.io), in festgelegten Versionen. Hinter einem Registry-Mirror überschreiben Sie die OSA_<TOOL>_IMAGE-Eingaben — siehe Container images.
• Einstellungen: Die Organisationsstandards gelten standardmäßig. Zur Anpassung fügen Sie eine der Dateien security/policy-global.yml, policy-licenses.yml, policy-semgrep.yml, policy-gitleaks.toml hinzu, die nur Ihre Abweichungen enthält — siehe Customizing oss-analyzer.
• Häufige Eingaben:

      inputs:
        OSA_DISTRIBUTION_MODEL: distributed   # saas | distributed | oss_library
        OSA_MODE: audit                       # onboarding: report everything, never block
        OSA_JOB_NEEDS: ["build"]              # wait for your build first
  

  Jede Eingabe ist auf der CI/CD-Katalog-Seite der Komponente und in templates/analyze.yml dokumentiert.
• Projekt mit einem Backlog: OSA_MODE: audit meldet alles und blockiert nichts. OSA_GATE_SCOPE: new blockiert weiterhin, was neu ist: bei einem Merge Request blockiert nur, was noch nicht im letzten erfolgreichen Bericht des Ziel-Branches enthalten ist; andernorts werden Befunde ohne Blockierung gemeldet (dafür sind Merge-Request-Pipelines erforderlich). Siehe Nur neue Befunde.
• MR-Zusammenfassungskommentar: OSA_ENABLE_MR_COMMENT: true veröffentlicht das Urteil, die blockierenden Befunde und den Dashboard-Link als einen Kommentar, der von jeder Pipeline aktualisiert wird. Es benötigt ein Projekt-Zugriffstoken (Scope api, Rolle Reporter) in einer maskierten CI/CD-Variable OSA_GITLAB_TOKEN.
• Maven-Projekt: Maven Central drosselt gemeinsam genutzte Runner, und der aufgelöste Abhängigkeitsgraph geht dann verloren. OSA_MAVEN_MIRROR_URL (z. B. ein Maven Central-Remote Ihres Artefakt-Repositories), mit einer maskierten Variable OSA_MAVEN_MIRROR_AUTH, falls Anmeldedaten erforderlich sind, löst stattdessen über einen Mirror auf — siehe Bekannte Fallstricke.
• Versionen: Pinnen Sie eine Minor-Version (@0.4 folgt seinen Patches). Die 0.x- Schnittstelle kann sich bis 1.0.0 noch ändern: Eine Breaking Change erhöht die Minor-Version, siehe CHANGELOG.md.

Wiederverwendbarer GitHub Actions-Workflow

jobs:
  security:
    uses: ThalesGroup/oss-analyzer/.github/workflows/security.yml@<ref>
    with:
      oss-analyzer-repository: ThalesGroup/oss-analyzer
      oss-analyzer-ref: <ref>   # the same ref as in `uses:`

Eingaben, Berechtigungen und Secrets: siehe GitHub Actions.

Lokale Analyse, ohne CI

Analysiere ein empfangenes Projektarchiv (.zip, .tar.gz) oder einen Ordner ohne CI einzurichten:

security/scripts/analyze-archive.sh my-project.zip

Der Bericht und ein HTML-Dashboard landen unter security-reports/<project-name>/ — siehe Usage.

Dokumentation

Die vollständige Dokumentation ist security/README.md: Einrichtung, jede Eingabe und Einstellung, die Berichte, bekannte Fallstricke. CHANGELOG.md listet die Versionen auf, Breaking Changes zuerst.

Warum oss-analyzer

Für jeden Belang gibt es gute Open-Source-Scanner: Semgrep, Gitleaks, Syft, Grype, OSV-Scanner, Trivy, cdxgen, REUSE. Was einem Team fehlt, ist selten ein weiterer Scanner. Es ist der Teil dazwischen: eine Entscheidung statt eines Haufens von Berichten, Regeln, die niedergeschrieben statt erinnert werden, und Lizenzen, die so ernst genommen werden wie CVEs. oss-analyzer ist dieser Teil.

Eine Analyse, die gesamte Software

Jeder Lauf betrachtet die drei Oberflächen dessen, was du auslieferst, gemeinsam: