Skip to main content

How to configure static analysis

When you'd do this: once per organisation when you first adopt the static-analysis policy, then per release when you decide which checks must pass before that release ships.

REQQA's static-analysis policy lets you declare, in one place, which automated code-quality and security checks your organisation cares about, how each tool's findings map onto REQQA's severity scale, and which checks a given release must satisfy. It is the machine-readable half of your quality bar: analysts curate it in the UI, and a Dark Factory builder reads it back through the profile API to know what it has to clean before a release is accepted.

The policy has three building blocks, and you set them up in order:

  1. Categories — the catalogue of what you check (style, type safety, SAST, dependency CVEs, accessibility, and so on), each with a default tool, gate, threshold, and severity floor.
  2. The rule knowledge base (KB) — individual tool rules (e.g. Bandit B608, Ruff F401), each with an explanation, a risk note, remediation guidance, and a normalised severity.
  3. Severity mappings — how each tool's native severity words (error, serious, CRITICAL, …) translate to REQQA's HIGH / MEDIUM / LOW scale.

Once those exist, you apply a profile to a release to set, per category, whether a check is required, advisory, or excluded for that release.

note

Everything here is organisation-scoped. Each organisation owns its own catalogue, KB, and severity map; one organisation's edits never affect another. The catalogue and KB are managed by your organisation's analysts using the org-member roles you already have — there is no separate static-analysis permission to grant.

Before you start​

You don't have to type the whole policy by hand. REQQA ships a canonical starting set — a 34-category catalogue, a knowledge-base stub, and a default severity map — that you seed into your organisation in one click each. Seeding is idempotent: it adds anything missing and skips anything already present, so re-seeding never overwrites edits you've made.

Step 1 — Seed and review your category catalogue​

Open the Category Catalogue page (saCategoryList). On a fresh organisation it will be empty.

  1. Click Seed catalogue. REQQA inserts the canonical 34 categories and reports, for example, "Catalogue seeded: 34 added, 0 already present."
  2. The categories are grouped by domain:
    • A — Source code quality (style, type safety, complexity, dead code, docs, architecture, test quality)
    • B — Security (code-level) (SAST, secrets, SQL safety, XSS, AI/prompt safety, PII)
    • C — Supply chain and dependencies (CVE scanning, licences, pinning, SBOM, container scan, drift)
    • D — Frontend and UX (HTML/CSS/JS lint, accessibility, i18n, prose)
    • E — Interface contracts (OpenAPI, IaC, schema drift)
    • F — Process hygiene (licence headers, commit format, docs build, markdown, spell check)
  3. Each row shows its code (e.g. A1, B2), name, default tool, gate, threshold, and severity floor. The floor is the lowest severity a finding in that category can be demoted to — for example, secrets scanning (B2) has a HIGH floor, so a leaked key is never filed as LOW.

Adding or editing a category​

The canonical set is a starting point, not a straitjacket. To add an organisation-specific check:

  1. Click Add category (saCategoryAdd).
  2. Fill in the Code (unique within your catalogue, upper-cased automatically), pick a Domain (A–F), and give it a Name.
  3. Set the default tool, default gate (e.g. pre-commit, ci, release), default threshold (the prose rule, such as "zero High; Medium triaged before release"), and a severity floor of HIGH, MEDIUM, or LOW.
  4. The default status records where the category sits on the adoption ladder — baseline, stop-the-bleed, triage, ratchet, or lock. Click Save.

To change an existing category, click its Edit link (saCategoryEdit). To retire one without losing its history, click Archive — archived categories drop off the active list but can be restored, and you can view them with the Show archived toggle.

tip

Edit the threshold text to say exactly what "passing" means for your team. This is the sentence a builder and a reviewer both read, so make it unambiguous — "branch coverage ≥ 60% on changed files" beats "good coverage".

Step 2 — Populate the rule knowledge base​

Where categories say what you check, the knowledge base explains individual rules. Open the Rule Knowledge Base page (saKbList).

  1. Click Seed KB to load the starter set. Each entry pairs a tool and a rule code (e.g. bandit / B608, ruff / F401, axe-core / color-contrast) with a plain-English explanation, a risk note, remediation advice, an upstream documentation URL, and a normalised severity.
  2. Use the filters at the top to narrow by tool, by normalised severity, or by a free-text search across rule code and name.
  3. To document a rule the starter set doesn't cover, click Add KB entry (saKbAdd). The tool plus rule code must be unique within your organisation. Optionally record the tool's native severity (the word the tool itself emits) alongside the normalised severity, and tag the entry with a category code (e.g. B2) so it ties back to the catalogue.

The knowledge base is what turns a terse tool output line into something a person — or REQQA — can act on: why it matters and how to fix it.

Step 3 — Define your severity mappings​

Different tools grade findings differently: Bandit says HIGH/MEDIUM/LOW, mypy says error, axe-core says serious, pip-audit says CRITICAL. The severity map normalises all of these onto REQQA's single HIGH / MEDIUM / LOW scale. Open the Severity Map page (saSeverityList).

  1. Click Seed severity map to load the default mappings (for example, mypy / error → HIGH, axe-core / serious → MEDIUM, pip-audit / CRITICAL → HIGH).
  2. To add or change a mapping, supply the tool, the native severity string, and the normalised severity (HIGH, MEDIUM, or LOW), then save (saSeveritySave). Edit an existing mapping with its Edit link (saSeverityEdit); remove one you don't need with Delete.
note

When a tool emits a severity that has no matching row, REQQA falls back to MEDIUM. An organisation-specific mapping always wins over a system-wide default, so you can override the shipped behaviour for any tool/severity pair.

Step 4 — Apply a profile to a release​

Categories, KB, and mappings describe your organisation's standing policy. A profile turns that standing policy into a per-release decision: for this release, which categories are required, which are merely advisory, and which are excluded.

Open the release (its scope) and go to the Static Analysis tab on the release view. If the catalogue is empty you can seed it from here too.

  1. Choose one of the four profiles and click Apply profile:
    • Strict — every active category is required.
    • Standard — domains A, B, C, and D are required; domains E and F are advisory.
    • Minimum — only the core set (A1, A2, A3, B1, B2, C1) is required; the rest are excluded.
    • Custom — everything starts advisory for you to set by hand.
  2. REQQA writes one policy row per active category for the release and reports how many it set, for example "Applied the Standard profile to 34 categories."
  3. Fine-tune individual categories on the tab: change a category's disposition (required / advisory / excluded), set its in-release status (not_started, in_progress, passed, waived), or override its threshold or severity floor for this release only. An override requires a rationale — if you tick override but leave the reason blank, REQQA saves the rest and tells you which categories it skipped. Click Save.
caution

Re-applying a profile resets every category's disposition to that profile's baseline. It deliberately preserves your per-category in-release status and any threshold or severity overrides — switching profiles is a disposition reset, not a wipe. If you've hand-tuned dispositions and don't want them reset, don't re-apply a profile; edit categories individually.

Result​

Your organisation has a populated static-analysis catalogue, a rule knowledge base that explains each finding, and a severity map that normalises every tool onto HIGH / MEDIUM / LOW. Each release you touch carries an explicit, reviewable profile saying which checks must pass before it ships — the same policy a Dark Factory builder reads back through the profile API to know exactly what it has to satisfy.