Merge pull request #80 from ai-ram-ramani/add-security-extensions

Add security extensions framework 

Later we need to address: comments for PR:
Token usage

Execution Time

Path ambiguity for extension scanning (Medium)
File: core-workflow.md:29

The extensions loading section says to scan extensions/ but doesn't specify relative to what. The rule details loading section above references .aidlc-rule-details/ as the base directory.
The actual file lives at aidlc-rules/aws-aidlc-rule-details/extensions/security/baseline/security-baseline.md. The scanning instruction should be explicit about the root path, e.g.
.aidlc-rule-details/extensions/.

Step 5.1 ordering relative to Step 6 (Medium)
File: requirements-analysis.md:93-102

Step 5.1 says to scan extensions for applicability questions and "include that question in the clarifying questions file created in Step 6." But Step 5.1 comes before Step 6 — at that
point the file doesn't exist yet. This is logically fine (gather the questions, then create the file in Step 6), but the phrasing "created in Step 6" in a step that precedes it may confuse
LLM execution. Consider rephrasing to something like: "collect these questions and include them when generating the clarifying questions file in Step 6."

.gitkeep files contain content (Low)
Files: hipaa/.gitkeep, pci-dss/.gitkeep, soc2/.gitkeep, customer-specific/.gitkeep

By convention, .gitkeep files are empty files used solely to preserve empty directories in git. These contain markdown content (5-11 lines each). Consider either:

Renaming them to README.md, or
Making them truly empty and putting the documentation elsewhere
OWASP 2025 reference may be premature (Low)
File: security-baseline.md:35 and the Appendix table

The rules reference "OWASP Top 10 (2025)" throughout. As of the knowledge cutoff, the latest official OWASP Top 10 is the 2021 edition. If a 2025 edition has been officially published,
this is fine — but if not, this should reference 2021 or drop the year qualifier to avoid confusion.

Missing OWASP mapping for some rules (Low)
File: security-baseline.md Appendix

Rules SECURITY-01 through SECURITY-07 are not mapped to any OWASP category in the appendix. The table only maps SECURITY-08 through SECURITY-15. For completeness, either:

Add mappings for SECURITY-01 through SECURITY-07 (e.g., SECURITY-01 maps to A02: Cryptographic Failures, SECURITY-05 maps to A03: Injection), or
Add a note explaining why they're excluded
No mechanism to load only specific compliance extensions (Low)
The core workflow scans extensions/ recursively and loads all .md files. Once someone adds HIPAA or PCI-DSS rules, they'll all be loaded together. The applicability question mechanism
helps (users can disable per-extension), but the loading itself could become expensive with many extensions. Consider whether the framework should support selective loading based on
directory, or if the current "load all, ask about each" approach is the intended design.

audit.md logging for skipped extensions not fully specified (Low)
File: core-workflow.md:40

The conditional enforcement section says "Skip disabled extensions and log the skip in audit.md" but doesn't define a format for these log entries. The existing audit log format in
core-workflow.md (lines 477-485) is structured. Consider specifying the expected format for extension skip entries to ensure consistency.

No versioning for extension rules (Low)
The security baseline has no version identifier. As rules evolve (e.g., updating OWASP mappings, adding/removing rules), there's no way to know which version of the rules were applied to a
given project. Consider adding a version field or date to the extension file header.

Author: harmjeff

aidlc-rules/aws-aidlc-rule-details/extensions/security/baseline/security-baseline.md

@@ -0,0 +1,5 @@
+# HIPAA Compliance Extensions
+
+This directory is reserved for HIPAA compliance extension rules.
+
+Extension files placed here will be automatically loaded and enforced when enabled during the Requirements Analysis phase.

aidlc-rules/aws-aidlc-rule-details/extensions/security/compliance/hipaa/.gitkeep

@@ -0,0 +1,5 @@
+# PCI-DSS Compliance Extensions
+
+This directory is reserved for PCI-DSS compliance extension rules.
+
+Extension files placed here will be automatically loaded and enforced when enabled during the Requirements Analysis phase.

aidlc-rules/aws-aidlc-rule-details/extensions/security/compliance/pci-dss/.gitkeep

@@ -0,0 +1,5 @@
+# SOC2 Compliance Extensions
+
+This directory is reserved for SOC2 compliance extension rules.
+
+Extension files placed here will be automatically loaded and enforced when enabled during the Requirements Analysis phase.

aidlc-rules/aws-aidlc-rule-details/extensions/security/compliance/soc2/.gitkeep

@@ -0,0 +1,11 @@
+# Customer-Specific Security Extensions
+
+This directory is reserved for organization-specific security extension rules.
+
+Customers can add their own custom security requirements here. Extension files placed in this directory will be automatically loaded and enforced when enabled during the Requirements Analysis phase.
+
+## Example Use Cases
+- Company-specific coding standards
+- Internal security policies
+- Industry-specific requirements not covered by standard compliance frameworks
+- Custom threat model requirements

aidlc-rules/aws-aidlc-rule-details/extensions/security/customer-specific/.gitkeep

@@ -90,6 +90,17 @@ Analyze whatever the user has provided:
 
 **When in doubt, ask questions** - incomplete requirements lead to poor implementations.
 
+### Step 5.1: Extension Applicability Questions
+
+**MANDATORY**: Scan all loaded extension files for an `## Applicability Question` section. For each extension that declares one, include that question in the clarifying questions file created in Step 6. After receiving answers, record each extension's enablement status in `aidlc-docs/aidlc-state.md` under `## Extension Configuration`:
+
+```markdown
+## Extension Configuration
+| Extension | Enabled | Decided At |
+|---|---|---|
+| [Extension Name] | [Yes/No] | Requirements Analysis |
+```
+
 ### Step 6: Generate Clarifying Questions (PROACTIVE APPROACH)
    - **ALWAYS** create `aidlc-docs/inception/requirements/requirement-verification-questions.md` unless requirements are exceptionally clear and complete
    - Ask questions about ANY missing, unclear, or ambiguous areas

aidlc-rules/aws-aidlc-rule-details/inception/requirements-analysis.md

@@ -25,6 +25,23 @@ All subsequent rule detail file references (e.g., `common/process-overview.md`,
 - Load `common/question-format-guide.md` for question formatting rules
 - Reference these throughout the workflow execution
 
+## MANDATORY: Extensions Loading
+**CRITICAL**: At workflow start, scan the `extensions/` directory recursively for all `.md` files. These are extension rule files that apply as cross-cutting constraints across the entire workflow.
+
+**Loading process**:
+1. List all subdirectories under `extensions/` (e.g., `extensions/security/`, `extensions/compliance/`)
+2. Load every `.md` file found within those subdirectories
+3. Each extension file defines its own verification criteria and enforcement rules as cross-cutting constraints
+
+**Enforcement**:
+- Extension rules are hard constraints, not optional guidance
+- At each stage, the model intelligently evaluates which extension rules are applicable based on the stage's purpose, the artifacts being produced, and the context of the work — enforce only those rules that are relevant
+- Rules that are not applicable to the current stage should be marked as N/A in the compliance summary (this is not a blocking finding)
+- Non-compliance with any applicable enabled extension rule is a **blocking finding** — do NOT present stage completion until resolved
+- When presenting stage completion, include a summary of extension rule compliance (compliant/non-compliant/N/A per rule, with brief rationale for N/A determinations)
+
+**Conditional Enforcement**: Extensions may be conditionally enabled/disabled. See `inception/requirements-analysis.md` for the collection mechanism. Before enforcing any extension at ANY stage, check its `Enabled` status in `aidlc-docs/aidlc-state.md` under `## Extension Configuration`. Skip disabled extensions and log the skip in audit.md. Default to enforced if no configuration exists. Extensions without an `## Applicability Question` are always enforced.
+
 ## MANDATORY: Content Validation
 **CRITICAL**: Before creating ANY file, you MUST validate content according to `common/content-validation.md` rules:
 - Validate Mermaid diagram syntax