NuGuard Static Analysis Guide

nuguard analyze works entirely from an AI-SBOM document — no running application, no network access required for the core pass. It looks at your application from two angles at once:

1. The AI stack itself — agents, models, tools, prompts, guardrails, and the data/privilege paths between them — using 30 built-in structural rules purpose-built for AI/agentic systems.
2. The rest of the software infrastructure around it — CI/CD pipelines, dependencies, IaC, containers, secrets, and supply-chain integrity — using 27 more structural rules plus five optional third-party scanners (OSV, Grype, Checkov, Trivy, Semgrep).

Both dimensions produce the same normalized Finding model, mapped to OWASP and MITRE ATLAS, and rendered as Markdown, SARIF, JSON, or CSV.

Quick Start

Static analysis only needs an AI-SBOM — no live target required.

Common changes:

• --source — path to the repo to scan (or --from-repo <url> --ref <branch> for a remote repo); enables the supply-chain rules and third-party scanners, which need repo access beyond the SBOM alone
• --format — markdown for human review, json for automation, sarif for code scanning, csv for spreadsheets
• --min-severity — raise to high/critical to cut noise once the codebase is triaged
• --fail-on — exit code 1 when any finding meets this severity (default high)

nuguard analyze --sbom app.sbom.json --source . --format markdown

What Gets Analyzed

1. The AI stack

30 structural rules (NGA-001–NGA-030) run against the AI-SBOM graph itself — no source code re-parsing, just reasoning over the nodes and edges NuGuard already extracted. This is where NuGuard differs from generic code scanners: it can flag combinations across component boundaries, like "this agent has write access to a HIPAA-classified datastore via a tool with no guardrail node in the graph," which a single-file scanner can't see.

Example finding (NGA-006, rendered Markdown):

#### 🟠 NGA-006 — Missing authentication on API endpoint '/api/health'

**Summary:** Endpoint '/api/health' has no AUTH node.
**Remediation:** Add authentication middleware (API key, JWT, OAuth 2.0) to '/api/health'.
Use an API gateway to centralise auth enforcement.
**Framework Mapping:** OWASP LLM Top 10: LLM06:2026 · OWASP Agentic Top 10: ASI02 ·
MITRE ATLAS: AML.T0040, AML.T0000, AML.T0016

2. The rest of the software infrastructure

27 more structural rules (NGA-SC-001–NGA-SC-027) — plus five optional third-party scanners — cover everything around the AI stack: the CI/CD pipeline that ships it, its dependencies, its IaC, and the containers it runs in. This is where a compromised build pipeline or a malicious package gets caught before it ever reaches the AI components above.

Rule coverage scales with --supply-chain-profile: ci (12 fast rules) → standard (24 rules, default) → full (all 27, adds the git-history heuristics above — slower since it walks commit history).

Third-party scanners, run concurrently alongside the structural rules and independently toggleable:

Every scanner that needs a binary is skipped, not failed, when that binary isn't installed — nuguard analyze always completes and the report's Tool Coverage table shows exactly what ran.

Example finding (NGA-SC-004, rendered Markdown):

#### 🟠 NGA-SC-004 — CI step uses unpinned global install

**Summary:** Workflow '.github/workflows/e2e-tests.yml' contains a step that runs an unpinned
global npm install or npx without a pinned version. This allows attackers who compromise a
package to inject malicious code into the CI environment.
**Remediation:** Pin global installs to exact versions (e.g. `npm install -g tool@1.2.3`) or use
a lockfile-based approach. Avoid unpinned npx calls in CI.
**Framework Mapping:** OWASP LLM Top 10: LLM04:2026 · OWASP Agentic Top 10: ASI04

MITRE ATLAS enrichment

Every NGA and NGA-SC finding is automatically annotated with its MITRE ATLAS technique ID(s), tactic, and confidence — no separate scan, just an enrichment pass over findings the structural rules already produced. On top of that, four ATLAS-native checks (ATLAS-NC-001–004) look for patterns no NGA rule directly covers: unpinned/unhashed external models, writable datastores reachable with no guardrail in the path, model↔deployment paths with no auth, and agents/tools with outbound-external capability. Disable with --no-atlas; add --llm to also get CVE correlation (cross-referencing OSV/Grype hits against ATLAS techniques) and an LLM-authored narrative summary per finding.

Compliance mappings

Every finding carries pre-computed references — no separate compliance pass to run:

• OWASP LLM Top 10 and OWASP Agentic Top 10 (ASI) — attached to both NGA and NGA-SC findings.
• OWASP Top 10 CI/CD Security Risks — attached to NGA-SC findings only, since those are the rules that actually reason about the CI/CD pipeline.
• MITRE ATLAS — see above.

These are the same references NuGuard's Policy Engine compliance assessment rolls up into a framework-level score.

Findings, output, and exit codes

Every finding — from NGA, NGA-SC, OSV, Grype, Checkov, Trivy, or Semgrep — normalizes into the same Finding model: finding_id, title, severity, description, affected_component, remediation, references, plus the OWASP/ATLAS fields above. Output formats: markdown (default, human review), json (automation), sarif (GitHub Code Scanning), csv (spreadsheets).

Exit codes: 0 clean, 1 findings at or above --fail-on (default high), 2 analysis/SBOM error.

📖 Need every flag?

🔀 Want to run a different test?