Notifications
Clear all
Topic starter
01/08/2026 10:43 pm
TL;DR: Document-level analysis creates explainability gaps that become harder to accept as AI takes on more of the review workload, according to Seezo. Its rebuilt architecture now breaks design documents into components, assets, and data flows before generating security requirements, so each finding maps to specific system parts and can support both machine reasoning and human review.
NHIMG editorial — based on content published by Seezo: Seezo Is Even Better Than Before. And It’s All In the Components
Questions worth separating out
Q: What breaks when AppSec tools only analyse design documents at a high level?
A: High-level document analysis often produces findings that are too broad to action cleanly.
Q: Why do component-level models matter when AI is used in AppSec?
A: Component-level models give AI a stable structure to reason over, which improves consistency and traceability.
Q: How do teams know whether AI-assisted AppSec is actually helping?
A: Look for findings that can be traced back to named components, repeated across assessments, and mapped to concrete remediation actions.
Practitioner guidance
- Require component-level traceability in every security finding Update AppSec review templates so each requirement names the component, asset, and data flow that triggered it.
- Align human review with machine-readable context graphs Use structured outputs that can be rendered as diagrams and queried by downstream systems.
- Plan for code mapping after component decomposition Do not attempt code integration until design artefacts are decomposed into stable components.
What's in the full article
Seezo's full blog post covers the architectural detail this post intentionally leaves at the governance level:
- How the component-first pipeline separates component identification, data-flow mapping, and security analysis into distinct steps
- Why the team chose different models for different tasks and how that affects runtime, quality, and supervision
- How the context graph supports persistent organisational memory across multiple assessments
- What the interactive DFD exposes about each node, including the metadata used to explain findings
👉 Read Seezo's full blog post on component-first AppSec architecture →
Component-first AppSec: what it means for security reviews?
Explore further
01/08/2026 10:53 pm
Component specificity is now a governance requirement, not a nice-to-have. Once security findings are generated at document level, organisations struggle to reuse them across code, architectures, and portfolios. A component-first model creates a stable unit of analysis that can be traced, challenged, and measured over time. For AppSec teams, the practical conclusion is that review quality now depends on whether the system can name the exact component at issue.
A question worth separating out:
Q: What should security teams do before connecting AppSec output to code?
A: They should first establish a structured representation of the application, including components, assets, and data flows. That gives code mapping a target. Without it, the organisation risks linking findings to the wrong place or creating confidence in mappings that are not actually grounded in the architecture.
👉 Read our full editorial: Component-first AppSec analysis is replacing document-only reviews
