Organisation policy

One set of rules, applied in the editor and in CI, so there are no surprises at the pull request.

Requires a signed-in organisation account.

The problem it solves

A developer’s editor says clean, CI says blocked. Both are running a scanner, neither is running the same configuration. So the developer learns to ignore their editor and wait for CI, which is the outcome an editor extension exists to prevent.

Vulnetix applies one policy in both places, retrieved from your organisation.

Quality gate

The thresholds that fail a build: severity, exploit maturity, malware, end-of-life dependencies, unpinned versions, version lag, and cooldown for freshly published packages.

Set centrally, applied everywhere. Where an organisation policy and a local setting disagree, the organisation wins, including over an explicitly passed flag. That is deliberate: a policy a developer can quietly opt out of is not a policy.

Package firewall

Which packages may be installed at all, enforced at install time rather than discovered afterwards. Blocks known-malicious packages, typosquats, and anything outside your allowlist.

AI firewall

For organisations routing AI coding assistants through a gateway: which providers and models are permitted, and guardrails on what may be sent.

The editor validates guardrail patterns as you write them. Patterns are Go RE2, which has no lookahead or lookbehind, and the gateway silently skips a pattern it cannot compile. A guardrail that is silently absent is worse than no guardrail, so the editor tells you before you save it.

Suppressions

Suppressions recorded in the editor sync to the organisation, so a decision made once is visible to everyone and applies in CI. Each carries who made it, when, why, and optionally when it expires.

Suppressions follow the code. When a suppressed finding moves because lines were added above it, the record is relocated using git history rather than going stale and re-firing.