Risk decisions
Not every finding gets fixed. Some are accepted deliberately, some are not real, and both are legitimate outcomes. What is not legitimate is either of them happening without a record.
The four decisions
| Decision | Requires | Use when |
|---|---|---|
| Start fixing | Nothing. A note is optional. | Work has begun. |
| Accept the risk | A written reason and a date it runs out | You are deliberately leaving this, for now. |
| Not a real issue | A written reason | A false positive, or something that does not apply to your context. |
| Reopen | Nothing | A previous decision was wrong, or circumstances changed. |
Decisions are made by an AppSec Lead on any finding's detail page.
Two rules, and why they exist
A suppression needs a reason
Accepting a risk or marking a false positive requires a written explanation. The reason is not for us. It is for whoever reads the finding in eight months, possibly during an incident, possibly during an audit, wondering why this was left. An unexplained suppression is indistinguishable from a mistake.
An acceptance needs an expiry
Every risk acceptance carries a date it runs out, and the longest permitted is one year. There is no permanent acceptance, because a permanent acceptance is how a backlog quietly becomes policy.
When the date passes, Sinterly reopens the finding automatically. The change is recorded as having been made by the system rather than by the last person to touch it, because putting somebody's name against a decision they did not take would corrupt the record. The daily sweep runs at 05:45 UTC, ahead of the main ingest, so your backlog and your gate verdict agree.
Acceptances approaching their expiry appear on the executive view before they lapse, so renewal is a decision somebody makes on purpose rather than something discovered when a build starts failing.
The record cannot be edited
Every decision writes to a finding's history, and that history is append-only in the database itself. Not by convention, and not enforced by the application, which could be bypassed. The database physically refuses updates and deletes.
If a decision cannot be recorded for any reason, the decision does not take effect either. A decision without its record is exactly the situation this design exists to prevent, so the product fails safely rather than quietly.
How decisions interact with the gate
A finding under a live risk acceptance does not fail your build. That is the point: a gate that ignores a documented, expiring, signed-off exception is a gate teams learn to route around.
The moment an acceptance lapses, the finding counts against the gate again. This happens to the second and does not wait for the daily sweep.
Override reporting
Suppressing a finding that meets the blocking policy is an override. Sinterly measures them:
override rate = overridden / (blocking + overridden)In words: of everything the policy says must be fixed, what share is being waved through. This is reported to your executives alongside something more useful than the raw count, namely whether each exception has a named owner, a written reason and an expiry date.
Suppressing something the policy would never have blocked is not an override and is not counted. Ordinary triage should not inflate the number, or it stops meaning anything.