Skill Being Reviewed
Skill name: threat-modeling
Skill path: skills/appsec/threat-modeling/
False Positive Analysis
Benign event-driven architecture that can be over-reported as untrusted:
flows:
- source: payment-service
destination: notification-service
protocol: AWS EventBridge (async event bus)
transport: TLS 1.3 + AWS SigV4 signing
auth: IAM role (sts:AssumeRole) with resource-based policy on event bus
data_classification: Internal (order confirmation event, no PII)
trust_boundary: Same AWS account, same OU
failure_mode: fail-closed (EventBridge DLQ + reprocess)Why this is a false positive:
The current skill prompts for trust boundary identification at every data flow, which is good, but it does not distinguish event-bus-mediated async flows from point-to-point synchronous flows. In an event-driven architecture, the event bus itself is a security boundary, and individual producers/consumers may not directly trust each other — they trust the bus. The skill's DFD template and per-flow annotation requirements do not account for broker-mediated trust models, so a reviewer may flag async bus flows as "crossing trust boundaries" when the bus is the only trust boundary, or miss flows that cross trust boundaries through the bus by checking only producer→bus and bus→consumer individually rather than the end-to-end data flow.
Benign service mesh sidecar that can be incorrectly flagged as unauthenticated:
flow:
source: order-service
destination: inventory-service
protocol: HTTP/2 (within mesh)
transport: mTLS (auto-rotated via Istio CA)
auth: SPIFFE identity (spiffe://cluster.local/ns/prod/sa/inventory)
annotation: |
mTLS is transparently enforced by the sidecar proxy.
Application code does not handle TLS or authentication.Why this is a false positive:
The skill's DFD annotation requirement for Authentication mechanism may produce "none" or "application-level only" if a reviewer examines only the application container-to-container connection without including the sidecar proxy as a process element. The sidecar enforces mTLS at the pod level, but the DFD template does not include sidecar proxies as explicit elements. Without guidance to model sidecars as inline security gateways, a reviewer may conclude the flow is unauthenticated.
Coverage Gaps
Missed variant 1: Trust boundary missed at CI/CD pipeline → artifact registry flow.
flows:
- source: CI/CD pipeline (GitHub Actions)
destination: Container Registry (ECR)
protocol: docker push over HTTPS
transport: TLS 1.3
auth: OIDC-based temporary credentials
trust_boundary: CI runner (ephemeral) → registry (persistent)
review_notes: |
The CI runner is an ephemeral, multi-tenant environment.
A compromised workflow_run or tampered artifact tag
bypasses the OIDC trust chain.Why it should be caught:
The skill lists CI/CD pipeline boundaries in the "Implicit Trust Boundary Discovery Checklist" (section 3, bullet: "CI/CD pipeline boundaries — Between source control, build system, artifact registry, and deployment target"), but the DFD template and per-flow annotation format do not include a field for artifact_integrity or build_provenance. Without these fields, a reviewer can identify that a pipeline boundary exists but has no structured way to record whether attestation (SLSA, Sigstore), artifact signing, or tag immutability is in place at each boundary.
Missed variant 2: Serverless function-to-function invocation through event bus with no direct trust.
flows:
- source: process-orders Lambda
destination: update-inventory Lambda
protocol: async invocation via EventBridge + SQS
transport: AWS-manigned TLS
auth: resource-based policy + SQS queue policy
trust_model: |
process-orders writes to EventBridge.
EventBridge routes to SQS.
update-inventory polls SQS.
No direct trust path between the two functions.Why it should be caught:
The skill's STRIDE-per-element analysis and risk matrix assume reviewer identification of individual components, but in a serverless event-driven architecture, the trust model is not a point-to-point relationship — it is a mediated relationship through managed services (EventBridge, SQS, SNS). The skill does not include a trust_model annotation classification that distinguishes "direct" from "mediated" trust. Without this, a reviewer can misclassify the flow's authentication and trust boundary placement.
Missed variant 3: Data flow crossing trust boundary through shared volume or sidecar.
flows:
- source: app-container
destination: sidecar-log-collector
protocol: shared emptyDir volume (Unix socket or file)
transport: local host only
auth: none (kernel isolation only)
trust_boundary: Same pod, different container
data_classification: Restricted (raw audit events)Why it should be caught:
The skill's DFD template and per-flow annotation are designed for network flows. They do not include non-network inter-process communication patterns: shared volumes, Unix domain sockets, shared memory, or eBPF-based data exchange. In Kubernetes, sidecar-to-application communication often uses localhost or shared volumes, which can bypass network-level controls. The skill should include a communication_type field (network, IPC, shared-storage, signal) and require that IPC-based flows be annotated with pod-level isolation context.
Edge Cases
- The skill lists "third-party SDK/library boundaries," but SDKs are often in-process — there is no network flow to annotate. Trust boundary analysis for in-process dependencies requires library isolation context (sandboxing, wasm isolation, capability-based security), which the DFD template does not capture.
- Multi-cloud service mesh with different CA trust domains: mTLS between services in different meshes (e.g., Istio to Consul Connect) may require bridge gateways. The DFD template has no field for cross-mesh mTLS or gateway-mediated trust.
- Zero-trust network (TLS) with application-layer delegation: a service may present a valid mTLS certificate but act on behalf of an end-user whose authorization is not verified by the downstream service. The DFD annotation has no
delegation_chain or impersonation_context field.
- Asynchronous flows with TTL or scheduled delivery: EventBridge schedules, SQS delayed queues, or Kafka consumer offsets affect the timeliness of threat detection but are not captured in the DFD template.
Remediation Quality
Recommended additions:
- Add a
trust_model per-flow field with values: direct (point-to-point authenticated), mediated (broker/bus-based with policy enforcement), sidecar (inline proxy), local_trust (same-process or same-node with kernel isolation).
- Add a
communication_type per-flow field with values: network, ipc_socket, shared_volume, shared_memory, in_process.
- Add a separate subsection for CI/CD and build-boundary flows with
artifact_integrity attestation evidence fields (SLSA level, provenance attestation, signature verification).
- Include template fixtures for event-bus-mediated flows, sidecar-mTLS flows, and serverless async invocations so reviewers have structural guidance for non-point-to-point architectures.
Comparison to Other Tools
| Tool |
Catches this? |
Notes |
| Microsoft Threat Modeling Tool |
Partial |
DFD-based, no explicit sidecar/bus trust model fields; relies on reviewer judgment |
| OWASP Threat Dragon |
Partial |
Same limitation — no mediated-trust or IPC communication type |
| Semgrep/CodeQL |
No |
These are source-code pattern matchers; they do not evaluate architecture-level trust models |
| IriusRisk |
Partial |
Supports trust boundary mapping but depends on reviewer input for mediated trust classification |
Overall Assessment
Strengths:
- Comprehensive STRIDE-per-element analysis with actionable threat register and risk matrix.
- Good implicit trust boundary discovery checklist covering inter-service, pod, network, cloud-account, CI/CD, and third-party SDK boundaries.
- Strong alignment with MITRE ATT&CK for traceability.
Needs improvement:
- The DFD template and per-flow annotation format are designed for point-to-point synchronous network flows and do not capture async-mediated, IPC-based, or sidecar-enforced trust relationships.
- The risk matrix and component-threat analysis lack guidance for event-driven, serverless, and mesh architectures where trust is mediated rather than point-to-point.
- CI/CD boundaries are listed in the checklist but have no structured fields in the per-flow annotation to capture artifact integrity evidence.
Priority recommendations:
- Add
trust_model (direct/mediated/sidecar/local_trust) and communication_type (network/IPC/shared-storage) per-flow fields to the DFD annotation requirements.
- Add a CI/CD-specific annotation subsection with artifact integrity and SLSA-level evidence fields.
- Add serverless/event-bus and service-mesh architecture fixtures to the template examples so reviewers have structural guidance for non-point-to-point architectures.
Sources Checked
Bounty Info
Skill Being Reviewed
Skill name: threat-modeling
Skill path:
skills/appsec/threat-modeling/False Positive Analysis
Benign event-driven architecture that can be over-reported as untrusted:
Why this is a false positive:
The current skill prompts for trust boundary identification at every data flow, which is good, but it does not distinguish event-bus-mediated async flows from point-to-point synchronous flows. In an event-driven architecture, the event bus itself is a security boundary, and individual producers/consumers may not directly trust each other — they trust the bus. The skill's DFD template and per-flow annotation requirements do not account for broker-mediated trust models, so a reviewer may flag async bus flows as "crossing trust boundaries" when the bus is the only trust boundary, or miss flows that cross trust boundaries through the bus by checking only producer→bus and bus→consumer individually rather than the end-to-end data flow.
Benign service mesh sidecar that can be incorrectly flagged as unauthenticated:
Why this is a false positive:
The skill's DFD annotation requirement for
Authentication mechanismmay produce "none" or "application-level only" if a reviewer examines only the application container-to-container connection without including the sidecar proxy as a process element. The sidecar enforces mTLS at the pod level, but the DFD template does not include sidecar proxies as explicit elements. Without guidance to model sidecars as inline security gateways, a reviewer may conclude the flow is unauthenticated.Coverage Gaps
Missed variant 1: Trust boundary missed at CI/CD pipeline → artifact registry flow.
Why it should be caught:
The skill lists CI/CD pipeline boundaries in the "Implicit Trust Boundary Discovery Checklist" (section 3, bullet: "CI/CD pipeline boundaries — Between source control, build system, artifact registry, and deployment target"), but the DFD template and per-flow annotation format do not include a field for
artifact_integrityorbuild_provenance. Without these fields, a reviewer can identify that a pipeline boundary exists but has no structured way to record whether attestation (SLSA, Sigstore), artifact signing, or tag immutability is in place at each boundary.Missed variant 2: Serverless function-to-function invocation through event bus with no direct trust.
Why it should be caught:
The skill's STRIDE-per-element analysis and risk matrix assume reviewer identification of individual components, but in a serverless event-driven architecture, the trust model is not a point-to-point relationship — it is a mediated relationship through managed services (EventBridge, SQS, SNS). The skill does not include a
trust_modelannotation classification that distinguishes "direct" from "mediated" trust. Without this, a reviewer can misclassify the flow's authentication and trust boundary placement.Missed variant 3: Data flow crossing trust boundary through shared volume or sidecar.
Why it should be caught:
The skill's DFD template and per-flow annotation are designed for network flows. They do not include non-network inter-process communication patterns: shared volumes, Unix domain sockets, shared memory, or eBPF-based data exchange. In Kubernetes, sidecar-to-application communication often uses localhost or shared volumes, which can bypass network-level controls. The skill should include a
communication_typefield (network, IPC, shared-storage, signal) and require that IPC-based flows be annotated with pod-level isolation context.Edge Cases
delegation_chainorimpersonation_contextfield.Remediation Quality
Recommended additions:
trust_modelper-flow field with values:direct(point-to-point authenticated),mediated(broker/bus-based with policy enforcement),sidecar(inline proxy),local_trust(same-process or same-node with kernel isolation).communication_typeper-flow field with values:network,ipc_socket,shared_volume,shared_memory,in_process.artifact_integrityattestation evidence fields (SLSA level, provenance attestation, signature verification).Comparison to Other Tools
Overall Assessment
Strengths:
Needs improvement:
Priority recommendations:
trust_model(direct/mediated/sidecar/local_trust) andcommunication_type(network/IPC/shared-storage) per-flow fields to the DFD annotation requirements.Sources Checked
skills/appsec/threat-modeling/SKILL.mdBounty Info