Skip to content

Security Gates

The shared security target combines Python static analysis, dependency vulnerability auditing, and optional package-specific dependency checks. bijux-canon-dev owns normalization of the pip-audit report; Make owns tool execution and artifact paths; package profiles own explicit exceptions and additional checks.

flowchart TD
    source[Package source] --> bandit[Bandit]
    environment[Resolved dependencies] --> audit[pip-audit]
    audit --> json[pip-audit.json]
    json --> gate[bijux-canon-dev audit gate]
    profile[Package security policy] --> gate
    profile --> extras[Package-specific dependency checks]
    bandit --> verdict[Security target verdict]
    gate --> verdict
    extras --> verdict

Gate Composition

Target Input Output beneath artifacts/<package>/security/
security-bandit configured Python source paths bandit.json, bandit.txt, isolated bytecode cache
security-audit active environment or prepared requirements pip-audit.json, pip-audit.txt, optional requirements file
security-deps package-specific helper targets adapter-specific reports or refusal
security all three surfaces combined exit status

Bandit excludes generated build, artifact, tox, mypy, and pytest-cache paths by default. A package can add explicit Bandit skip IDs or flags. SKIP_BANDIT=1 is visible in the text artifact; it means the analysis was skipped, not passed.

Dependency Audit Policy

The audit path produces machine-readable JSON and a human-readable report. When the repository helper is configured, security.pip_audit_gate accepts either pip-audit’s list form or its dependency-envelope form and evaluates every vulnerability.

flowchart LR
    report[Audit JSON] --> parse{Readable and recognized?}
    parse -- no --> strict{Strict mode?}
    parse -- yes --> ids[Collect primary IDs and aliases]
    ids --> ignored[Apply explicit ignore set]
    ignored --> remaining{Findings remain?}
    remaining -- no --> pass[Pass with counts]
    remaining -- yes --> strict
    strict -- yes --> fail[Nonzero refusal]
    strict -- no --> visible[Visible non-strict continuation]

Ignore matching checks both the vulnerability’s primary ID and aliases. The text report states which IDs are ignored and how many vulnerability instances matched. An ignore entry suppresses the gate finding; it does not patch the dependency or establish that the advisory is irrelevant.

Package profiles can carry different ignore sets because their resolved dependency graphs differ. Every exception remains checked-in, reviewable, and specific. Add an exception only with a documented applicability decision and a removal trigger; do not broaden it to make unrelated packages green.

Strict and Non-Strict Behavior

SECURITY_STRICT=1 is the default. In strict mode:

  • a Bandit refusal fails its target;
  • a missing, malformed, or unexpected audit report exits with configuration failure;
  • unignored vulnerabilities fail the audit target;
  • a pip-audit invocation failure remains nonzero.

Non-strict mode keeps findings and invocation problems visible but allows the target to continue. It is appropriate only for an explicitly informational run and must never be reported as equivalent to strict verification.

The combined target preserves the tool’s nonzero status. Wrappers must not append unconditional success, discard the report, or treat an absent JSON file as an empty vulnerability set.

Investigation Order

Symptom Inspect first Normal response
Bandit finding rule ID, source line, JSON confidence/severity correct code or add the narrowest reviewed suppression
audit vulnerability package, installed version, all IDs/aliases, fix versions update dependency and lock; assess consumers
ignored finding checked-in package ignore set and advisory status verify applicability and removal condition
unreadable report pip-audit invocation and pip-audit.json repair tool/environment; do not classify as clean
audit invocation code greater than one pip-audit.txt, environment, index access treat as tooling failure rather than vulnerability verdict
package dependency refusal package adapter report correct the package’s declared boundary

Retain both JSON and text artifacts. JSON supports deterministic processing; text records the operator-facing interpretation and invocation failure.

Scope of the Claim

These gates establish static Python findings and known vulnerabilities in the audited dependency resolution under the checked-in policy. They do not by themselves prove:

  • runtime isolation, authorization, or tenant separation;
  • safe handling of every external tool or model response;
  • absence of leaked secrets in deployment systems;
  • container, host, or network hardening;
  • exploitability or non-exploitability of an ignored advisory.

Product packages document their own threat boundaries and runtime controls. Deployment systems remain responsible for credentials, network policy, sandboxing, patch cadence, and incident response.

See Quality Gates for evidence selection, SBOM and Supply Chain for dependency inventory, and the package security guide for product-specific controls.