Structural weakness engine

How Veriom detects design conditions with deterministic invariants, bounded paths, propagated confidence, and independently reviewable evidence.

Architecture reasoning you can reproduce

A structural weakness is a condition where the system can behave exactly as implemented and still permit an unsafe outcome. Veriom detects these conditions over its canonical model; scanner observations can support a conclusion, but they do not decide it.

Detection stays deterministic

Language models may explain a finding or propose a target state. They do not decide whether an invariant passed or failed. The invariant ID, version, input evidence, and evaluation result remain reproducible across audits.

What every structural finding contains

Part	What it answers
Label and layer	Which design pattern is involved, and whether it belongs to code, cloud, CI/CD, IaC, runtime, or crosses layers?
Detection	Which versioned invariant evaluated, in which audit, and was the result reproducible?
Structure	Which entities, relationships, and trust boundaries form the asserted path?
Evidence	Which independent ledgers corroborate the claim, and which expected ledgers are missing?
Confidence	What is the propagated path confidence, its floor, and whether the result is asserted or remains a hypothesis?
Criticality	Which crown jewels are reachable and how that changes the response priority?
Root cause	Which stable provenance key groups recurring manifestations of the same design decision?
Remediation	Which target state should replace the current structure, and what predicate proves the change worked?
Taxonomy	Which immutable taxonomy snapshot supplied the displayed CWE, CAPEC, OWASP, and ATT&CK references?

Initial invariant pack

The first pack covers nine high-value conditions:

an untrusted workload holds production administration;
one workload identity crosses trust zones;
caller identity terminates before a privileged operation;
tenant-scoped access lacks data-layer tenant binding;
network location substitutes for workload identity;
a mutable privileged pipeline accepts an untrusted trigger;
a runner keeps a long-lived cloud credential;
a production artifact cannot be traced to an approved immutable build; and
defence-in-depth controls share one failure dependency.

Each definition states its required ledgers, preferred corroboration, confidence floor, severity basis, remediation tier, verification predicate, and positive plus benign fixtures. A typed YAML predicate DSL is validated and compiled into a bounded process cache. The evaluator interprets that predicate rather than branching on the invariant ID, which keeps renamed and future versioned rules reproducible.

Paths are bounded and evidence-aware

Veriom evaluates reachable paths with a bounded, deterministic search. A hop is eligible only when its declared preconditions are met and its evidence clears the configured confidence floor. Path confidence uses a grouped product rather than copying the strongest edge score, so a multi-hop claim cannot masquerade as a single high-confidence observation.

Some invariants describe a direct condition, such as a tenant-scoped write without tenant binding. Those findings use the confidence of the cited direct evidence and do not invent a path. The finding contract labels the structure as direct or path, so reviewers can distinguish the two.

If a required ledger is absent, the engine returns insufficient evidence, not pass. The UI shows the missing ledgers and a coverage note so an operator knows whether to collect more evidence or reject the hypothesis.

Root causes survive across audits

Findings are grouped by normalized provenance such as an IaC module and version, image digest, workload identity, reusable pipeline, shared code pattern, or origin change. A root cause receives a stable identity and tracks the audits and member findings in which it was observed. That makes claims such as “fixing the shared module closed 25 findings” verifiable by re-observation.

Each causal group also projects every entity and relationship in the latest truth snapshot that carries the same immutable provenance key. The recurrence view shows confidence, sources, evidence references, and whether each manifestation has an active finding. It includes matches with no current finding so teams can size a systemic change before the same invariant fails elsewhere.

When an enforced invariant no longer matches on a later evidence-complete audit, Veriom records that absence as verification evidence. It closes the finding with closed_by: reobservation only after the exact remediation pull request is confirmed merged, the environment is observed by a newer completed audit, the verification predicate is false, and the regression check passes. If the same stable condition returns, the lifecycle becomes regressed without creating a second identity.

Remediation is explicit about what can be automated

R1 deterministic changes one evidence-backed artifact and can proceed through the managed patch, offline scanner, human approval, and draft pull-request flow.
R2 scaffolded generates the mechanical policy, middleware, migration, or network-policy portion, but publication is blocked until a human records the missing scope decision. That decision is preserved in the audit trail and pull request.
R3 sequenced cannot be represented honestly as one patch. The single-remediation API rejects it so a multi-step, evidence-gated program can own the target state. A program requires at least two workspace repositories and two accountable scopes. Each ordered step names an invariant version and predicate; a later step stays locked until a newer completed audit records that exact invariant as passing. Failed or missing evaluations block the program without erasing its proof history.

Every R1 and R2 structural pull request contains the invariant statement and version, graph verification predicate, evidence IDs, root-cause reference, and a machine-readable contract under .veriom/structural-tests/. The contract records the failing baseline and required passing post-patch state for customer-owned CI. Veriom reruns offline static scanners but does not claim to have executed customer builds, tests, scripts, or repository code. Post-deployment closure additionally requires the exact invariant version to pass against a newer truth snapshot; an absent evaluation remains partial rather than being treated as success.

Crown jewels require review

Workspace developers can propose a critical asset only by referencing an entity already present in architectural truth. An analyst, administrator, or owner confirms or rejects the proposal with a reason. The versioned, audited register then influences blast-radius and priority calculations; a scanner cannot silently designate a crown jewel.

Taxonomy does not alter detection

External framework references decorate a result at render time. Reports pin an immutable taxonomy snapshot, while the current UI may also show newer mappings. Updating a CWE or OWASP label never changes the invariant result, finding identity, root-cause identity, or lifecycle state.

The control worker checks code-owned sources on a bounded schedule: CISA KEV and FIRST EPSS daily; CWE, CAPEC, ATT&CK, and OWASP Top 10 weekly; and OWASP CI/CD Top 10 monthly. Downloads are restricted to fixed HTTPS hosts and size limits. CWE XML, CAPEC/ATT&CK STIX, KEV JSON, and EPSS gzip records normalize automatically. OWASP Markdown changes enter review_required and cannot be published into a snapshot until an operator records human review. Interrupted or failed syncs retry hourly and surface as an operator alert and release-readiness block.

Taxonomy sources are normalized in scheduled or operator-controlled ingest jobs. Each version records added, updated, retired, and superseded nodes. Narrative OWASP sources require an explicit human-review acknowledgement before publication, and publication hashes the complete normalized snapshot.

Manual VRM-to-framework mappings are reviewed in the operator console and become active only when the next immutable snapshot is published. CAPEC, ATT&CK, and OWASP references can then derive through native CWE links at reduced confidence. Deprecated CWE references retain the original ID and resolve their successor as a separate inherited reference, so historical evidence never breaks.

After each architecture observation, Veriom recomputes a workspace applicability profile from evidenced entity kinds and technology claims. Out-of-profile references remain stored and reviewable behind a disclosure; they are never deleted, and an incomplete profile does not hide a reference. Approved reports pin the exact taxonomy snapshot in both the report record and canonical payload. Approval is blocked until that pin exists, and a historical report labels its original snapshot separately from the current release.

Drift from declared intent

Implemented and previously verified architecture decisions are re-evaluated whenever a newer, sufficiently covered truth snapshot is produced. A failed machine-readable success criterion becomes a stable drift finding that keeps the declared representation, the observed result, the evidence references, and the ledgers that disagree. Inconclusive absence checks remain explicit as insufficient evidence. A later observation resolves the drift only when the same criterion passes.

Workspace invariant learning

An agent or analyst may propose an organization-specific invariant only through the same finite, interpreted predicate language as the code-owned pack. The candidate must include inline true-positive and benign fixture graphs. Veriom evaluates every fixture twice, rejects non-deterministic output, rejects a positive fixture that does not fail, and rejects a benign fixture that does not pass.

A workspace administrator can move a reviewed candidate into shadow mode. Enforcement is a separate transition requiring at least 50 reviewed samples and observed precision at or above the candidate budget. If later reviewed precision drops below that budget, evaluation automatically returns the candidate to shadow. Definitions stay workspace-scoped and cannot reuse a code-owned invariant ID and version.

Continuous self-falsification

Each current truth snapshot contributes to a deterministic, bounded weekly sample of asserted architecture relationships. Reviewers inspect the cited evidence and record the edge as confirmed, disproved, or inconclusive. Disproved edges are accuracy failures—not customer weaknesses—and remain visible in the operator metric. This makes “how often our own claims survive an attempted disproof” measurable without executing customer code or sending source material to an unrestricted model.

Review one finding

Confirm the invariant ID, version, and evaluation state.
Follow the entity path and inspect evidence on each hop.
Check crossed boundaries, reachable crown jewels, and control independence.
Compare present and missing evidence ledgers.
Confirm the root-cause provenance and affected manifestations.
Review the target state and verification predicate before approving work.