Skip to content

Add threat model for the policy repo - #1794

Merged
st3penta merged 1 commit into
conforma:mainfrom
st3penta:EC-2003
Aug 7, 2026
Merged

Add threat model for the policy repo#1794
st3penta merged 1 commit into
conforma:mainfrom
st3penta:EC-2003

Conversation

@st3penta

@st3penta st3penta commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Add THREAT_MODEL.md following the wg-agentic-sdlc 8-section schema, covering
the policy repo's specific threat surface: how Rego rules evaluate attestation
data, where logic gaps can cause silent passes, and how the policy bundle
distribution chain can be compromised.

Entry points cover attestation data, the 4-level rule_data precedence cascade,
OCI blob fetching, trusted task rules (both rules system and legacy), sigstore
configuration, volatile config exclusions, and bundle distribution. Threats are
organized into input evasion, data poisoning, logic errors, supply chain, and
denial of service categories.

Cross-references the CLI threat model (EC-2001) for CLI-level concerns rather
than duplicating them.

Notable finding: policy bundles pushed to quay.io are unsigned. Digest pinning
mitigates tag mutation but doesn't prove provenance.

Ref: https://issues.redhat.com/browse/EC-2003

Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com

@qodo-for-conforma

Copy link
Copy Markdown

PR Summary by Qodo

Add threat model document for conforma/policy

📝 Documentation 🕐 20-40 Minutes

Grey Divider

AI Description

• Add a repo-specific threat model for how Rego policies consume verified inputs.
• Document trust boundaries around rule_data precedence, trusted tasks, and OCI fetching.
• Capture supply-chain risks in bundle distribution and recommended mitigations (incl. signing).
Diagram

graph TD
  R[("OCI Registry")] --> C["Conforma CLI"] --> O["OPA Engine"] --> P["Policy (Rego)"] --> G["Gate decision"]
  I["Image + attestations"] --> C
Loading
High-Level Assessment

The chosen approach (a standalone THREAT_MODEL.md aligned to the wg-agentic-sdlc schema and cross-referencing the CLI threat model) is the most maintainable option for this repo. Alternatives like embedding this into SECURITY.md or duplicating CLI-side concerns would either dilute focus or create drift across repos.

Files changed (1) +399 / -0

Documentation (1) +399 / -0
THREAT_MODEL.mdAdd comprehensive threat model for conforma/policy +399/-0

Add comprehensive threat model for conforma/policy

• Introduces an 8-section threat model covering assets, trust boundaries, and threat categories specific to Rego policy evaluation and policy bundle distribution. Documents key inputs like attestation data, the 4-level rule_data precedence cascade, trusted task rule merging, sigstore config, volatile config, and OCI blob fetching, and highlights unsigned bundle risk with recommended mitigations.

THREAT_MODEL.md

@coderabbitai

coderabbitai Bot commented Aug 6, 2026

Copy link
Copy Markdown
📝 Walkthrough

Walkthrough

Added THREAT_MODEL.md. The document describes Conforma policy evaluation, critical assets, trust boundaries, threats, open questions, provenance, and prioritized remediation recommendations.

Changes

Policy threat model

Layer / File(s) Summary
System context, assets, and trust boundaries
THREAT_MODEL.md
Documents policy evaluation flows, input and data sources, critical assets, entry points, and trust assumptions.
Threat analysis and open questions
THREAT_MODEL.md
Catalogs threats, impacts, likelihoods, mitigations, deprioritized threats, and unresolved security questions.
Provenance and remediation priorities
THREAT_MODEL.md
Records document provenance and prioritizes recommendations for bundle signing, rule-data validation, collection checks, trusted-task handling, and data-source integrity.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely identifies the addition of a threat model for the policy repository.
Description check ✅ Passed The description explains what changed, provides context, links the related issue, and summarizes the documented threat areas.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands.

@codecov

codecov Bot commented Aug 6, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag Coverage Δ
unit-tests 100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@qodo-for-conforma

qodo-for-conforma Bot commented Aug 6, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Grey Divider


Remediation recommended

1. Wrong attestations file path ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
THREAT_MODEL.md references lib/attestations.rego, but the attestations selection logic lives in
policy/release/lib/attestations.rego (and the provenance section already cites that correct path).
This breaks traceability for reviewers/auditors validating security-relevant behavior
(latest-attestation selection).
Code

THREAT_MODEL.md[R93-96]

+materials, and SBOM content. Nearly every deny/warn rule in `policy/release/`
+consumes attestation fields. When multiple attestations of the same type exist,
+`lib/attestations.rego` selects the latest by `buildFinishedOn` timestamp.
+
Relevance

●●● Strong

Doc/path fix is low-risk and improves traceability; similar doc-correction feedback has been
accepted.

PR-#1779
PR-#1789

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The document references lib/attestations.rego in the entry-point section, but later lists
policy/release/lib/attestations.rego as the actual source; the latter file contains the
buildFinishedOn-based latest-attestation selection logic.

THREAT_MODEL.md[91-96]
THREAT_MODEL.md[333-340]
policy/release/lib/attestations.rego[43-79]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`THREAT_MODEL.md` references a non-existent/incorrect repo path (`lib/attestations.rego`) for the attestation-selection logic. The correct file is `policy/release/lib/attestations.rego`.

### Issue Context
The threat model is intended to be used for security review and audit. Incorrect paths slow verification and can lead to reviewers inspecting the wrong code.

### Fix Focus Areas
- THREAT_MODEL.md[91-96]
- THREAT_MODEL.md[244-251]
- THREAT_MODEL.md[333-340]

### Suggested change
- Replace `lib/attestations.rego` with `policy/release/lib/attestations.rego` (or explicitly refer to the OPA package name `data.lib` if that was the intent), and keep references consistent with the provenance section.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

2. Misleading AGENTS.md reference ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
THREAT_MODEL.md claims the guard-rule pattern is documented in AGENTS.md, but the referenced
AGENTS.md section only covers general Rego semantics and does not describe the guard-rule/data-found
prerequisite pattern. This misdirects contributors looking for implementation guidance on avoiding
silent passes.
Code

THREAT_MODEL.md[267]

+| LE-1 | **Implicit pass from Rego semantics**: a rule with an unmet precondition produces no output, which OPA treats as "no violation". This is inherent to Rego's design and the primary logic-class risk. | High: silent pass for unexpected input shapes. | Medium: new rules are at risk of this unless the author explicitly follows the guard-rule pattern. | Some packages implement guard rules. Pattern documented in AGENTS.md Rego evaluation model guidance. Not enforced by linting or CI. |
Relevance

●●● Strong

Correcting misleading cross-reference in docs matches prior accepted documentation-clarification
changes.

PR-#1789
PR-#1779

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
THREAT_MODEL.md asserts AGENTS.md documents the guard-rule pattern, but the cited Rego Evaluation
Model section in AGENTS.md contains only general semantic guidance and no guard-rule/data-found
pattern description.

THREAT_MODEL.md[265-268]
AGENTS.md[60-75]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`THREAT_MODEL.md` states that the guard-rule pattern is documented in `AGENTS.md`, but `AGENTS.md` does not currently document that specific pattern.

### Issue Context
This is a documentation accuracy issue: readers following the reference won’t find the promised guidance.

### Fix Focus Areas
- THREAT_MODEL.md[265-268]
- AGENTS.md[60-75]

### Suggested change (pick one)
1) Update `THREAT_MODEL.md` to remove/soften the claim (e.g., say the pattern is *recommended* but not yet documented/enforced), or point to a section that actually documents it.
2) Add a short “Guard rule / data found prerequisites” subsection to `AGENTS.md` under “Rego Evaluation Model” and keep the THREAT_MODEL reference.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Context used
⚠️ Tickets: not configured — ticket URL found in PR but could not be fetched — check ticket provider credentials
✅ Compliance rules (platform): 19 rules

To customize comments, go to the Qodo configuration screen, or learn more in the docs.

Qodo Logo

Comment thread THREAT_MODEL.md
Comment thread THREAT_MODEL.md Outdated

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 5

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@THREAT_MODEL.md`:
- Around line 41-43: Reconcile the attestation trust boundary in
THREAT_MODEL.md: update the statements around the Rego rules and lib/intoto so
they clearly distinguish CLI/lib/intoto signature and trusted-task verification
from rule evaluation, and state the exact verification assumption for
input.attestations, including the explicit skip-verification path.
- Around line 194-196: The threat model incorrectly presents the two Quay
repositories in the push-bundles workflow as independent registry fallback.
Update the mitigation text around the GitHub Actions workflow entry to remove
that claim, or document a genuine client failover or cache path instead; do not
treat the enterprise-contract and conforma repositories as separate failure
domains.
- Around line 279-280: Update the SC-4 threat-model entry to limit go.sum to
verifying downloaded-byte integrity, not publisher provenance or intentional
malicious updates, and do not present renovate.json as a trust control. Document
exact versions for the go run dependencies github.com/conforma/cli and
oras.land/oras/cmd/oras, along with the required provenance verification or
review control for dependency updates.
- Around line 176-190: The OCI blob fetching section for ec.oci.* builtins lacks
documented controls for registry scope, redirects, credentials, response size,
and request duration. Update the “Trust boundary” documentation to identify the
exact CLI or environment controls governing each applicable behavior, and
document fail-closed handling for malformed or unavailable OCI responses; if no
control exists, explicitly state that and describe the enforced behavior.
- Line 285: Revise the DS-1 threat-model entry to remove the unsupported claim
that OPA evaluation is generally linear, unless the system’s Rego rules are
verified against OPA’s linear-time fragment and supported by benchmarks.
Document Tekton Chains’ practical attestation and SBOM size limits for
Kubernetes etcd, OCI registries, and Rekor, including each backend’s maximum
supported size, and specify whether CLI timeouts fail, drop the attestation, or
stall the pipeline.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Enterprise

Run ID: b5dd8b65-fdc7-4999-90e7-af79a2875bcc

📥 Commits

Reviewing files that changed from the base of the PR and between 5713903 and 29ef6fc.

📒 Files selected for processing (1)
  • THREAT_MODEL.md

Comment thread THREAT_MODEL.md Outdated
Comment thread THREAT_MODEL.md
Comment thread THREAT_MODEL.md
Comment thread THREAT_MODEL.md Outdated
Comment thread THREAT_MODEL.md Outdated
@fullsend-ai-review

Copy link
Copy Markdown

🤖 Review · Started 3:29 PM UTC
Commit: 87c4a29 · View workflow run →

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Aug 6, 2026

Copy link
Copy Markdown

Note

GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer.

@fullsend-ai-review

Copy link
Copy Markdown

Review

Reason: stale-head

The review agent reviewed commit 72f7e66c9a5c46fcfe5c45fee7940ce7a3786db8 but the PR HEAD is now 705203367ddbd75a6eb096638bd74acd4600583e. This review was discarded to avoid approving unreviewed code.

@fullsend-ai-review

Copy link
Copy Markdown

/fs-review

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
THREAT_MODEL.md (1)

275-275: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick win

Correct the trusted-task precedence documentation.

_trusted_task_rules_data combines system and ruleData rules. Any matching effective deny rule blocks trust. A task is trusted only when no deny rule matches and at least one allow rule matches. Therefore, concatenation order and pattern specificity cannot let a ruleData allow rule override a system deny rule. Update LE-4 and remove Open Question 3.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@THREAT_MODEL.md` at line 275, Update the LE-4 entry in THREAT_MODEL.md to
state that _trusted_task_rules_data combines system and ruleData rules, any
matching deny blocks trust, and trust requires no deny match plus at least one
allow match; clarify that concatenation order and pattern specificity cannot
override a system deny with a ruleData allow. Remove Open Question 3.

Source: Path instructions

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@THREAT_MODEL.md`:
- Line 290: Update the DS-1 threat-model entry to distinguish OCI attestation,
manifest, and raw blob size limits, labeling the approximately 4 MiB value as
the manifest limit and removing any implication that the 500 MiB tar-entry limit
applies to ec.oci.blob raw SBOM blobs. Document the CLI evaluation timeout
behavior, including the default 5-minute --timeout and whether expiration
returns an evaluation error or may produce an undefined result.

---

Nitpick comments:
In `@THREAT_MODEL.md`:
- Line 275: Update the LE-4 entry in THREAT_MODEL.md to state that
_trusted_task_rules_data combines system and ruleData rules, any matching deny
blocks trust, and trust requires no deny match plus at least one allow match;
clarify that concatenation order and pattern specificity cannot override a
system deny with a ruleData allow. Remove Open Question 3.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Enterprise

Run ID: 930b3567-cb65-4717-a601-380b4864ba5f

📥 Commits

Reviewing files that changed from the base of the PR and between 5713903 and 7052033.

📒 Files selected for processing (1)
  • THREAT_MODEL.md

Comment thread THREAT_MODEL.md
@st3penta
st3penta merged commit 198e647 into conforma:main Aug 7, 2026
19 of 22 checks passed
@st3penta
st3penta deleted the EC-2003 branch August 7, 2026 07:31
@fullsend-ai-retro

fullsend-ai-retro Bot commented Aug 7, 2026

Copy link
Copy Markdown

🤖 Finished Retro · ✅ Success · Started 7:32 AM UTC · Completed 7:48 AM UTC
Commit: 87c4a29 · View workflow run →

@fullsend-ai-retro

Copy link
Copy Markdown

Retro: PR #1794 — Add threat model for the policy repo

Outcome: PR merged with zero completed fullsend reviews despite four separate review dispatch attempts. All findings map to existing open issues — no new proposals needed.

Timeline

  1. 15:09 — PR opened by st3penta adding THREAT_MODEL.md (+404 lines, single file). Branch EC-2003 from fork.
  2. 15:09 — First review dispatched (run 31114485852) → GitHub infra failure (Service Unavailable, 3 retries over 4 min).
  3. 15:10–15:15 — Bot reviews posted: qodo caught 2 issues (wrong file path lib/attestations.regopolicy/release/lib/attestations.rego, misleading AGENTS.md reference). CodeRabbit posted 5 actionable comments (attestation verification boundary, Quay failover claim, go.sum provenance claim, linearity claim, OCI controls).
  4. 15:27–15:28 — st3penta responds to all review comments and force-pushes fixes.
  5. 15:27 — Second review dispatched (run 31115871452) → runs for ~20 min.
  6. 15:41 — st3penta force-pushes again (addressing CodeRabbit round 2). This triggers a synchronize event.
  7. 15:41 — Third review dispatch trigger (run 31117014196) → GitHub infra failure again (Service Unavailable).
  8. 15:45 — Second review run completes with APPROVE verdict + 2 low-severity findings (trusted-task merge semantics omission, rule_data.get() empty-list edge case). Three sub-agents (style-conventions, docs-currency, intent-coherence) initially failed because claude-sonnet-4-5@20250929 was unavailable, then succeeded on retry without model override.
  9. 15:46 — Review discarded as stale-head: reviewed commit 72f7e66 but HEAD was now 7052033. Bot posts /fs-review redispatch comment.
  10. 15:46 — Redispatch comment triggers fullsend.yaml (runs 31117324457, 31117325372) → both SKIPPED because fullsend.yaml filters out issue_comment events from Bot users (github.event.comment.user.type != 'Bot'). The stale-head redispatch is dead code.
  11. 16:14 — Human reviewer joejstuart approves.
  12. 07:31 (Aug 7) — PR merged by st3penta.

What went well

  • Bot reviews were complementary: qodo caught path errors, CodeRabbit caught factual inaccuracies about Quay failover and go.sum provenance, and the fullsend review agent (before discard) found different issues about trusted-task merge semantics. Each review source added unique value.
  • Author was responsive: st3penta addressed all substantive review feedback within ~15 minutes, including fixing file paths, removing unsupported claims, and softening overstated mitigations.
  • The fullsend review agent's analysis was sound: its APPROVE verdict with 2 low findings was appropriate for a well-researched documentation PR. The challenger pass correctly downgraded speculative findings.

Evidence for existing issues

Autonomy readiness

No autonomy-readiness assessment is possible for this PR because the fullsend review never completed. The human reviewer (joejstuart) approved without inline comments. The discarded fullsend review would have approved with 2 low findings — findings that were different from and complementary to what qodo and CodeRabbit caught. This suggests the review agent adds unique value on documentation PRs, but the pipeline reliability issues prevented that value from being delivered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants