threagile

Threagile uses a set of built-in risk rules to analyze your threat model and identify potential security risks. These rules automatically scan your model for patterns that indicate vulnerabilities such as missing authentication, unencrypted communication, or injection risks.

Commonly identified risks include:

• Access & Boundary Risks: DoS-risky Access Across Trust-Boundary, Unguarded Access From Internet, Wrong Trust Boundary Content.
• Injection & Web Risks: Search-Query Injection, SQL/NoSQL-Injection, Cross-Site Scripting (XSS), Cross-Site Request Forgery (CSRF), XML External Entity (XXE), LDAP-Injection, Path-Traversal, Server-Side Request Forgery (SSRF).
• Infrastructure & Deployment Risks: Missing Build Infrastructure, Missing Cloud Hardening, Missing Network Segmentation, Push instead of Pull Deployment, Container Platform Escape.
• Data & Secret Risks: Accidental Secret Leak, Missing Vault (Secret Storage), Unencrypted Communication, Unnecessary Data Transfer.
• Identity & Auth Risks: Missing Authentication, Missing Identity Propagation, Missing Two-Factor Authentication (2FA), Missing Identity Store.

You can also define your own logic by creating custom risk rules.

The match: section determines which technical assets trigger a risk. The engine iterates over all technical assets and evaluates the logic provided in the do: block.

Best Practices:

• Respect Scoping: Always include - false: "{tech_asset.out_of_scope}" in your and conditions to ensure out-of-scope assets are not flagged.
• Filter by Tag: Use the contains operator on {tech_asset.tags}.
• Filter by Technology: Use the any operator on {tech_asset.technologies} to check for specific attributes (e.g., {.attributes.web-application}).
• Logical Operators: Use and, or, and not to combine conditions.

# Filter by tag
match:
  parameter: tech_asset
  do:
    - if:
        and:
          - false: "{tech_asset.out_of_scope}"
          - contains:
              item: my-tag
              in: "{tech_asset.tags}"
        then:
          return: true

# Filter by technology attribute
match:
  parameter: tech_asset
  do:
    - if:
        and:
          - false: "{tech_asset.out_of_scope}"
          - any:
              in: "{tech_asset.technologies}"
              true: "{.attributes.web-application}"
        then:
          return: true

For complex logic, use the utils: section to define reusable methods. Methods are case-insensitive.

Capabilities:

• Parameters: Define inputs for the method.
• Logic: Use assign, if, loop, return, and equal-or-greater.
• Model Access: Access the global model using the {$model.path.to.data} syntax.
• Iteration: Use loop to iterate over collections like tech_asset.data_assets_processed.
• Comparison: When comparing enum values (like confidentiality or criticality), use the as keyword in comparison expressions to perform semantic comparison rather than plain string comparison.

Example: Dynamic Impact Calculation

utils:
  get_impact:
    parameters:
      - tech_asset
    do:
      - assign:
          - impact: low
          - highest_confidentiality: "get_highest({tech_asset}, confidentiality)"
      - if:
          or:
            - equal-or-greater:
                as: confidentiality
                first: "{highest_confidentiality}"
                second: confidential
          then:
            - assign:
                impact: medium
      - return: "{impact}"

A Threagile model is defined in a yaml file and must comply with the project's JSON schema. The model is built around two primary types of assets:

1. technical_assets: The core components of your system. This is the starting point for any model.
2. data_assets: Definitions of the data that is stored, processed, or transmitted by technical assets.

To build a complete model, you must establish relationships between these assets using the following fields within your technical assets:

• communication_links: Describes how technical assets connect to one another. Within these links, you should specify data_assets_sent to indicate what data is moving between assets.
• data_assets_processed: Identifies which data assets a technical asset operates on.
• data_assets_stored: Identifies which data assets a technical asset holds.

Additionally, you can group assets using:

• trust_boundaries: To define security zones.
• shared_runtime: To group assets that share the same execution environment.