Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[FEATURE]: add threat detection coverage field to AI/ML-BOM (modelCard.threatDetection)

Open
  • Is something wrong?
#927 13 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
json
Domain
machine-learning, security

Research direction

Start by reviewing the existing AI/ML-BOM modelCard structure and the CDXA or in-toto attestation options named in the issue. Resolve the preferred schema location, treatment of matched rule identifiers, and scope before drafting schema text. Done means maintainers agree on the design and the resulting proposal is ready for a PR.

Written by the indexing model from the issue text.

Description

cap: ai/ml

This issue proposes adding a threat-detection coverage field to the AI/ML-BOM (modelCard) so that an AI/ML-BOM can declare which detection rulesets the model or agent artifact was scanned against, at what version, and with what outcome. The current AI/ML-BOM captures provenance, model parameters, considerations, and quantitative analysis, but does not capture agent-specific or model-specific threat detection coverage. As more AI agent artifacts (Model Context Protocol servers, Claude Code skills, agent configuration manifests) ship through SBOM-aware supply chains, consumers and registries are starting to ask: was this artifact scanned against a known agent-threat ruleset, which ruleset, which version, and what was the outcome.

I am proposing this as an issue rather than a PR because the right schema location (modelCard.threatDetection vs a separate top-level vs a CDXA attestation) is a design call that benefits from maintainer input before code changes. Concrete sketch in JSON Schema style for a modelCard.threatDetection field:

threatDetection: object, optional, describing the detection coverage applied to the AI/ML artifact.

threatDetection.scans: array of scan objects, each describing one scan run.

  scans[].scanner: object with uri (ResourceURI) and version (string), identifying the tool that performed the scan.

  scans[].ruleset: object with uri (ResourceURI) and version (string), identifying the ruleset that was applied. The version SHOULD be stable so a consumer can resolve any matched rule identifier.

  scans[].scannedAt: timestamp (RFC 3339).

  scans[].outcome: enum string, one of pass, warn, fail.

  scans[].matches: optional array of matched rules; each match has ruleId (string), severity (low/medium/high/critical), threatClass (string, e.g. prompt_injection, tool_poisoning, mcp_request_forgery, skill_compromise), and optional evidence (string).

This is ruleset-agnostic. One concrete example of a ruleset that fits is Agent Threat Rules (ATR), an open detection standard for AI agent threats licensed Apache-2.0, available at https://github.com/Agent-Threat-Rule/agent-threat-rules. ATR is currently shipped in production at Cisco AI Defense and Microsoft agent-governance-toolkit. The proposed field is not coupled to ATR; any ruleset issuing stable identifiers can populate it.

Three questions I would like maintainer guidance on before opening a PR. First, is modelCard.threatDetection the right home, or would maintainers prefer this as a CDXA attestation that references the BOM subject? Second, should the matched rule identifiers live inline in the BOM, or should the BOM reference an external attestation (in-toto or otherwise) and only carry a coverage summary? Third, given the cap: ai/ml label and capability scope, should this be scoped to AI/ML-BOM only, or generalized to any component that may have a corresponding agent-threat scan? I will draft schema text for whichever direction maintainers prefer and follow up with a PR.

Dominant language
XSLT
Stars
551
Forks
93
Avg merge
8h 13m
Merged PRs (30d)
23

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CycloneDX/specification

All issues in CycloneDX/specification

Similar issues

More Machine Learning issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.