Compliance
What an auditor can check.
Guardrail Ledger keeps the record behind each pull request gate: which scanners ran, what they found, whether the PR passed, and who accepted a finding instead of fixing it.
-
Exception ledger
Every accepted finding has an owner, an approver, a reason, and an expiry date. The approver has to be someone other than the owner.
-
Gate decision per run
Each pipeline run records the repository, commit, pull request, the engines that ran, and how many findings failed the gate.
-
Findings with context
Rule, severity, file, and line come from the scanner's SARIF. For secrets we keep the location, not the value.
-
Your threshold
You decide which severity fails the pull request: critical, high, medium, or low. Changing it is logged.
-
Audit log
Exception approvals, gate policy changes, SARIF uploads, and pipeline token changes are logged with who made them and when.
-
GDPR, DORA, and NIS2
We help with GDPR, DORA, and NIS2. When a reviewer asks about secure development, the ledger shows which risk was accepted, who signed, and until when.
What each exception records.
- Finding Engine, rule, severity, and repository
- Owner The person who asked for the exception
- Approver A second person, never the owner
- Reason Why the finding stays, in their words
- Expiry date Required, and always in the future
- Logged Who created it and when
From finding to record.
-
The scan runs on your agent
The pipeline task runs Trivy, Gitleaks, Checkov, and Opengrep and sends SARIF. Source code stays in your tenant.
-
The gate decides
Findings at or above your severity threshold fail the pull request, unless an exception covers them.
-
Someone signs
An exception needs an owner, a different approver, a reason, and an expiry date.
-
It runs out
After the expiry date, the next scan counts the finding against the gate again.
Put sign-off on file.
Run the scanners on your agents. We keep the gate decisions, the exceptions, and who approved them.