Tags: awslabs/aidlc-workflows
Tags
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.
fix: correct GitHub Copilot instructions and Kiro CLI rule-details pa… …th resolution (#82, #84) (#87) * fix: correct GitHub Copilot setup instructions (#82) Replace incorrect .copilot/instructions.md and COPILOT.md setup with the officially supported .github/copilot-instructions.md approach, which is auto-detected by VS Code and applied to all chat requests. - Remove Option 1 (.copilot/ directory) and Option 2 (COPILOT.md) - Add setup using .github/copilot-instructions.md per VS Code docs - Update troubleshooting tips for GitHub Copilot - Update version control recommendations to match new paths * fix: place rule details inside steering directory for Kiro CLI (#84) Kiro CLI resolves relative paths from the steering file location, not the project root. Move .aidlc-rule-details/ into .kiro/steering/aws-aidlc-rules/ so that references in core-workflow.md resolve correctly without modifying the shared workflow file. - Update Kiro CLI setup commands for all platforms - Update directory structure diagram - Add explanatory note about Kiro CLI path resolution - Add troubleshooting tip for rule details placement * fix: restore platform-specific fallback paths for rule details loading (#84) Kiro CLI resolves relative paths in steering files relative to the steering file location, not the workspace root. The consolidation to a single .aidlc-rule-details/ path caused Kiro CLI to look for rule details at .kiro/steering/aws-aidlc-rules/.aidlc-rule-details/, which does not exist. Restore the original fallback path order so the agent checks these paths and uses the first one found: - .aidlc-rule-details/ (Cursor, Cline, Claude Code, GitHub Copilot) - .kiro/aws-aidlc-rule-details/ (Kiro IDE and CLI) - .amazonq/aws-aidlc-rule-details/ (Amazon Q Developer)
docs: add Windows CMD setup instructions and ZIP note (#68) Add Windows CMD equivalents for mkdir and cp commands in both Kiro and Amazon Q Developer setup sections. Also add a note about the directory structure difference when using ZIP downloads from the Releases page. Closes #57 Co-authored-by: Riku Inada <inariku@amazon.com>