Notarisation never blocks.
The first step, wisec_notify, collects, signs and sends the build, then hands back. Your pipeline carries on while Wisec analyses.
Which rules must a build meet to go on, and who decides?
You write block or warn policies for your organisation. The Wisec gate enforces them in your pipeline, after analysis, and shows what was broken.
The first step, wisec_notify, collects, signs and sends the build, then hands back. Your pipeline carries on while Wisec analyses.
At the end of the pipeline, wisec-agent --gate polls Wisec until the analysis is done, then reads the result of your policies.
A hardcoded secret, a CVE above your threshold, a critical file changed, an unapproved contributor, a score under your minimum: the gate exits with an error and shows the violations.
A vulnerability declared not affected or fixed in the signed VEX is removed from the gate. The secret still blocks: it has to come out of the code.
Each policy has an action: block fails the gate, warn is logged without failing. They are managed per organisation, by an administrator.
| Policy | Evaluated | Fires on |
|---|---|---|
| secrets_detected | before analysis | A hardcoded secret found by gitleaks |
| critical_file_modified | before analysis | A change to a critical file (CI configuration, Dockerfile…) |
| unapproved_contributor | before analysis | A commit author missing from your approved contributors |
| cve_severity | after analysis | A CVE at or above your severity threshold |
| risk_threshold | after analysis | A build security score under your minimum |
The gate is the only place a policy blocks. Without the wisec_gate step, no block policy ever fails your pipeline: the build is notarised, nothing more.
./wisec-agent --gate