.svg)
PRESENCE
Does the element exist?
Check whether the designed component is present in the observed system.
AUTOMATED THREAT MODELING · DESIGN-TO-DEPLOYMENT VALIDATION
Find where the implemented system diverges from the approved design.
Compare supported architecture attributes with the approved model. Connect requirements to code and deployment evidence, scanner findings, guardrail results and remediation.
Approved design: a private service with no external entry point.
Implementation change
A new listener introduces an external flow absent from the approved model.
Deployment evidence
Confirm the listener’s exposure in the target environment and deployed revision.
Review action
Review the affected boundary and requirements. Remediate or submit a model change.
DESIGN-TO-DEPLOYMENT VALIDATION
Compare the approved architecture with the implemented system.
Heeler compares supported components, flows and security attributes against the approved model. Review new entry points, changed boundaries and unmet requirements, with evidence tied to the analyzed code and deployed environment.
Illustrative change: a new public listener creates an entry point outside the approved architecture.
Choose the comparison that fits the requirement.
Heeler compares supported attributes and shows where the implementation diverges from the approved architecture.
STRUCTURAL
Has security weakened?
Compare supported authentication, boundary and data-class attributes for security-weakening differences.
STRICT
Do selected attributes match?
Compare the supported attributes in both directions.
CODE VERSUS DEPLOYMENT
A verified code change is not proof of the deployed result.
If production runs a different revision, Heeler keeps that gap visible. Reviewers can distinguish verified implementation, partial evidence and requirements that have not been evaluated.
Illustrative evidence states. An enabled blocking check does not prove the mitigation is implemented.
Review architecture, findings and deployment evidence together.
Each part of the platform answers a different question about the same change. Keep requirement verification separate from enforcement results.
Illustrative workflow.
Connect each implementation gap to a fix and a recheck.
Keep the engineering change linked to the requirement and affected environment. Updated evidence shows whether the supported implementation check is satisfied.
Illustrative workflow.
Residual likelihood, impact and risk acceptance remain reviewer decisions.
Explore SAST Auto-fixTechnical questions
Does a verified requirement mean the whole system is secure?
It means the available evidence satisfies that requirement within its supported scope. Coverage gaps and checks requiring manual evidence remain visible.
Does a verified mitigation automatically lower the risk score?
Implementation evidence and risk rating are separate. Residual likelihood and impact remain explicit decisions.
Can it judge every internal network path?
The reviewed conformance scope does not include general internal-network exposure verification. Results depend on the supported observed attributes and available analysis.
Reopen approval when its basis changes.
Heeler compares the approval basis on resubmission. Agent proposals are reviewed and accepted changes applied before the resulting model is approved.
Approval follows the reviewed model version, including accepted changes and applicable conditions.
Record risk ownership, expiry and remediation.
Make accepted risk traceable to the design and the decision maker. Track unmet requirements, overdue decisions and unowned risks across applications, with detailed evidence available from the portfolio view.
Keep implementation tasks connected to the requirement so security and engineering can distinguish work in progress from evidence that the requirement is satisfied.
Keep the model, remediation and risk record connected.
Link implementation evidence and acceptance records with Archer, ServiceNow, Vanta or OneTrust. Read, link and push risk records with explicit field ownership.
Illustrative workflow.
Surface conflicting records.
If the external register says “closed” while local acceptance remains active, Heeler shows the disagreement. Local rules govern revocation; optional auto-revocation must be explicitly configured.
AUTOMATED THREAT MODELING · FROM PROMPT TO RUNTIME
