TL;DR: Its Enterprise API uses GraphQL to return fleet-wide container vulnerability and policy data in a single query, replacing chained REST calls with typed filters, paginated responses and runtime inventory views that show which vulnerable images are actually running, according to Anchore. The shift matters because reporting quality now depends on query design, schema understanding and access scope, not just image scanning.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Anchore's blog post: Anchore Enterprise GraphQL reporting for container security shows how one query can unify vulnerability, policy and runtime inventory data across a fleet.
Why it matters: It matters because container security teams need reporting that supports governance and response decisions across images, registries and live runtime assets, not just per-image lookups.
Context
Container security reporting often breaks down when teams have to stitch together image, vulnerability and runtime data across separate queries and views. GraphQL changes the reporting model by letting teams ask for the exact fields they need in one request, which is useful when the question is fleet-wide exposure rather than a single artifact.
That matters for governance as much as for operations. When live runtime inventory is folded into the same reporting layer, teams can distinguish between theoretical exposure and what is actually running, which is a stronger basis for prioritisation than static image lists alone.
Key questions
Q: How should container teams design fleet-wide security reporting instead of per-image queries?
A: Container teams should design reporting around the decision they need to make, not around the storage shape of the data. Fleet-wide reporting works best when one query can combine vulnerability exposure, policy state and runtime inventory, while preserving filters and pagination. That approach reduces manual joining and gives governance teams a consistent view of risk across registries, repositories and live clusters.
Q: Why is runtime inventory important when prioritising container vulnerabilities?
A: Runtime inventory matters because a vulnerability only becomes immediate operational risk when the affected image is actually deployed. Static registry data can overstate or understate exposure if it is not matched to live Kubernetes or ECS usage. Prioritisation should therefore start with runtime presence, then move to severity, fix availability and workload criticality.
Q: What do security teams get wrong about policy compliance reporting for containers?
A: Teams often flatten policy data too early and lose the distinction between registries, repositories, tags and evaluation records. That creates stale or misleading summaries, especially when each tag has multiple evaluations and only the latest result reflects current posture. Good reporting keeps the hierarchy intact until the final presentation layer.
Q: When does API access become part of container security governance?
A: API access becomes governance when reporting credentials can expose fleet-wide security state, especially across multiple accounts. At that point the query endpoint, account boundary and credential scope are control decisions, not implementation details. Teams should manage those credentials like other non-human identities, with least privilege, ownership and review.
Technical breakdown
How GraphQL reporting changes container vulnerability queries
GraphQL replaces multiple REST round trips with a single schema-driven request that returns only the fields a client asks for. In this context, the important shift is not just convenience. It is the ability to query across images, tags, artifacts and vulnerability metadata in one response, with typed filters and pagination built in. That makes fleet-level analysis more consistent, because the shape of the response is stable even when the underlying reporting questions differ. For container teams, this reduces client-side joining and filtering, which is where reporting drift and missed context often appear.
Practical implication: Use GraphQL when you need repeatable fleet-wide reporting rather than ad hoc per-image lookups.
Why runtime inventory matters in container security reporting
Runtime inventory adds the missing state dimension to container vulnerability reporting. Static image findings tell you what exists in a registry or artifact list, but runtime inventory tells you what is actually deployed in Kubernetes or ECS at the moment of analysis. That distinction matters because exposure only becomes operationally relevant when vulnerable images are running in a live environment. In this schema, runtime-scoped queries let teams pivot from theoretical risk to current blast radius, which is a different governance question from simple image hygiene. See the Container Security Guide.
Practical implication: Prioritise runtime-scoped queries when remediation decisions depend on what is actively running.
How policy evaluation hierarchies shape compliance reporting
Policy reporting in GraphQL is hierarchical, moving from registry to repository to tag and then to evaluation records. That structure is useful because compliance status is rarely flat. A single tag can produce multiple evaluation records, and the latest field becomes the practical way to identify the current outcome. This is a reporting design choice, not just a data model detail. If teams flatten policy data without preserving recency and hierarchy, they can misread stale failures as current drift or miss the current status entirely.
Practical implication: Preserve hierarchy and recency when building compliance dashboards from policy evaluation data.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
GraphQL is becoming a governance interface, not just an API style. In container security, the value of GraphQL is that it exposes fleet-wide state in a form that supports governance questions, not only developer convenience. That is particularly relevant when the same query layer can span vulnerability exposure, policy posture and runtime inventory. The practitioner implication is that reporting architecture now shapes control visibility.
Runtime context is the missing control boundary in many container programmes. Static inventory and vulnerability lists are not enough when the business question is whether a vulnerable image is actually active in a cluster. Anchoring analysis to runtime inventory narrows the gap between scan results and operational risk. Practitioners should treat runtime-aware reporting as a control requirement, not an optional enrichment.
Container reporting fails when hierarchy is flattened too early. Registry, repository, tag and evaluation are not interchangeable layers, and the latest result field shows why recency matters in policy reporting. If teams collapse those layers into a single summary, they lose traceability and can misstate current compliance. The practical conclusion is to preserve hierarchical evidence all the way to the dashboard.
Machine identity still sits underneath container reporting, even when the article is about queries. The account-scoped versus global GraphQL endpoints, the required account header and the authenticated API access model all depend on governed service access. In a container programme, API keys and service credentials are themselves non-human identities that deserve inventory, scoping and revocation discipline. Practitioners should apply the same control thinking to reporting access that they apply to runtime workloads.
Read next: Container Security Buyer's Guide
What this signals
Query architecture now influences container risk visibility. As container environments spread across registries and runtime platforms, the reporting layer becomes part of the control plane. Teams that still depend on per-image lookups will keep paying a coordination penalty whenever they need to answer a fleet question.
Runtime-aware reporting is the named concept this pattern exposes. It means the gap between artifact state and live deployment state is now a security decision point, not a reporting convenience. That gap is where prioritisation, response and evidence quality diverge, so container programmes should make runtime context a default in their reporting design.
For practitioners
- Define fleet-wide reporting questions first Separate per-image troubleshooting from governance reporting before you build the query layer. Use fleet questions such as vulnerability exposure across tags or policy status across registries so the API design matches the operational decision you need to make.
- Use runtime inventory for prioritisation Base remediation sequencing on what is actually running in clusters, not only on what is present in registries. That gives security teams a truer blast-radius view when a critical vulnerability affects multiple image versions.
- Preserve evaluation hierarchy in dashboards Keep registry, repository, tag and evaluation layers separate in reporting logic so you do not lose the latest compliance state. Flatten only after you have preserved the current result and the evidence behind it.
- Treat API access as governed service access Scope reporting credentials to the smallest viable account boundary and review who can query global views. The account header and endpoint choice in this model show that reporting access itself needs lifecycle control.
Key takeaways
- Container vulnerability reporting becomes more useful when one query can return exposure, policy and runtime context together.
- The central governance problem is not data volume but whether teams can distinguish static image findings from what is actively running.
- Practitioners should treat reporting architecture, runtime inventory and API access scope as part of the container security control surface.
Related NHI Mgmt Group resources: Container Security Guide · Container Security Buyer's Guide · Data Exfiltration Guide · API Security Buyer's Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | The article is fundamentally about querying and inventorying API-exposed security data across container assets. |
| Recommendation — Use API9-style inventory discipline to keep container assets, query surfaces and reporting scopes continuously enumerated. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | GraphQL access is scoped by account and administrator permissions, so authorisation governs who can see fleet data. |
| Recommendation — Apply PR.AA-05 to restrict reporting access by account boundary and administrative role. | ||
| CIS Controls v8 | CIS-5 — Account Management | The authenticated query model and account header make reporting access an account management issue. |
| Recommendation — Use CIS-5 to review who can query global container security data and revoke unnecessary access. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The account-scoped and global endpoints show why least privilege matters for reporting credentials. |
| Recommendation — Apply AC-6 to limit GraphQL reporting credentials to the narrowest account scope possible. | ||
| MITRE ATT&CK | TA0007;TA0009 — Discovery; Collection | Fleet-wide security queries support discovery and collection of vulnerability and policy data across environments. |
| Recommendation — Map fleet reporting to discovery and collection needs so defenders can enumerate exposed images and gather current posture data. | ||
Key terms
- GraphQL reporting: GraphQL reporting is a query approach that lets a client request exactly the data fields it needs from a schema in one response. In security tooling, it reduces client-side joining and filtering, which makes fleet-level analysis faster and more consistent when teams need a repeatable view.
- Runtime inventory truth: A governance approach in which the authoritative view of APIs comes from observed production behaviour rather than static documentation. It is the basis for aligning discovery, monitoring, and enforcement with the real service landscape.
- Hierarchical policy evaluation: Hierarchical policy evaluation is a reporting structure that preserves multiple layers of context, such as registry, repository, tag and evaluation result. It matters because current compliance status can only be interpreted correctly when the current result and its lineage are both retained.
- Account-scoped access: Account-scoped access limits a user or service to the data for one defined boundary, rather than the whole platform. In a reporting API, this is a governance control that reduces unnecessary visibility and helps separate operational users from administrators with broader reach.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org