Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
# Q CLI Project Context Setup

This directory contains configuration files to provide automatic project context for Q CLI sessions.

## Files

- **`project-context.md`** - Comprehensive project overview, architecture, and development guidelines
- **`config.json`** - Q CLI configuration to auto-load project context
- **`README.md`** - This file

## How It Works

When you start a new Q CLI session in this project directory, the configuration will:

1. **Auto-load project context** from `project-context.md`
2. **Set working directory** to the project root
3. **Apply safety guidelines** - Q will not modify files unless explicitly requested
4. **Provide architecture awareness** - Q understands the Step Functions workflow, Lambda functions, and infrastructure

## Usage

Simply run Q CLI from the project root:

```bash
cd /Users/roficas/aws-infrastructure-reverse-engineering
q chat
```

Q will automatically have context about:
- ✅ System architecture (Step Functions, Lambda, DynamoDB, S3)
- ✅ Component relationships and dependencies
- ✅ Development guidelines and best practices
- ✅ Security considerations and IAM architecture
- ✅ Branch strategy (main vs mcp-server)

## Safety Features

The configuration includes safety instructions:
- 🛡️ **Read-only by default** - Q won't modify files without explicit permission
- 🛡️ **Confirmation required** - Q will ask before making changes
- 🛡️ **Impact explanation** - Q will explain consequences of proposed changes
- 🛡️ **Security focus** - Maintains security best practices for this security system

## Project Overview Reminder

This is a **serverless AWS security configuration analysis system** that:
- Processes security configurations via S3 uploads
- Uses Step Functions to orchestrate AI-powered analysis
- Generates security controls, IAM models, and IaC templates
- Leverages Amazon Bedrock for intelligent recommendations
- Maintains audit trails and compliance mappings

The system is production-ready on the `main` branch, with experimental MCP server integration available on the `mcp-server` branch.
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
{
"name": "aws-security-agent",
"description": "AWS Security Configuration System project assistant",
"prompt": "You are working on the AWS Security Configuration System project. Before responding to any user query, read and understand the project context from .amazonq/project-context.md. This context contains critical information about the system architecture, components, and development guidelines. IMPORTANT: Do not apply any code changes unless explicitly requested by the user. Always ask for confirmation before modifying files and explain the impact of proposed changes. Do not deploy any code unless explicitly asked.",
"resources": [
"file://.amazonq/rules/project-context.md",
"file://.amazonq/rules/security-system-guidelines.md"
],
"allowedTools": [
"fs_read",
"fs_write",
"execute_bash",
"use_aws"
],
"toolsSettings": {
"fs_read": {
"allowedPaths": ["./"]
},
"fs_write": {
"allowedPaths": ["./"]
}
}
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
{
"defaultAgent": "aws-security-agent"
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,49 @@
# Security Configuration System Rules

## Working Environment
- **Work locally only** - do not attempt AWS deployments or account changes, unless explicitly asked
- Focus on code development, testing, and local validation
- Use existing test outputs and local files for analysis

## Code Style & Implementation
- Follow minimal implementation principle - write only essential code
- Use existing Lambda layers and shared utilities
- Maintain consistency with current CDK stack structure
- Follow AWS security best practices with least privilege IAM

## Architecture Constraints
- All Lambda functions must use Python 3.10 runtime
- Use existing DynamoDB table naming convention: `gensec-{TableName}`
- S3 buckets follow pattern: `gensec-{purpose}-{account}-{region}`
- Lambda functions use prefix: `gensec-{FunctionName}`

## Development Guidelines
- Test changes in decomposed architecture (current active system)
- Use existing Lambda layers: common, bedrock, dynamodb-operations, validation, requests, web-scraping
- Environment variables must reference CDK-managed resource names
- All resources must include gensec tags

## Output and Testing Standards
- All generated outputs must be saved to `tests/output` directory
- All test files and test data must be placed in `tests/` directory
- Scripts should default to `tests/output` for generated content
- Maintain organized subdirectories within tests for different output types

## Bedrock Integration
- Use Strands Agent (GenSecAgent) when USE_STRANDS_AGENT=true
- Support both direct model calls and agent-based processing
- Implement pagination for large parameter sets
- Log all AI interactions for debugging

## Data Flow Requirements
- Security profiles and service requests trigger Step Functions workflow
- All outputs stored in S3 with structured paths
- DynamoDB used for tracking, validation, and service documentation
- Support both individual file processing and batch operations

## Current Development Priorities
- Implement pagination for Bedrock calls with large parameter sets
- Replace web scraping with MCP server integration
- Develop AgentCore to centralize Bedrock interactions
- Improve validation logic to reduce false positives
- Add SQS integration: S3→SQS→StepFunctions
Original file line number Diff line number Diff line change
@@ -0,0 +1,29 @@
# Security Configuration System Guidelines

## 🚨 CRITICAL: READ-ONLY BY DEFAULT
- **DO NOT modify files** unless explicitly requested
- **Ask confirmation** before any changes
- **Explain impact** of proposed changes
- **Preserve functionality** unless specifically changing it

## Project Context
**Serverless security configuration analysis system** that automates AWS service security recommendations using AI. Processes service configurations and generates security controls, IAM models, and infrastructure templates through Step Functions workflow.

## Architecture Components
- **Workflow**: gensec-SecurityConfigWorkflow (ValidateAndCollectServiceData → AnalyzeSecurityRequirements → GenerateSecurityControls → GenerateIaCTemplate → GenerateServiceProfile → GenerateIAMModel)
- **Lambda Functions**: SecurityProfileProcessor, AWSServiceDocumentationManager, AnalyzeSecurityRequirements, GenerateSecurityControls, GenerateIaCTemplate, GenerateIAMModel, GenerateServiceProfile
- **Storage**: DynamoDB (SecurityControlLibrary, ServiceRequestTracking, AWSService* tables), S3 (input/output/documentation)

## Development Rules
- **scripts/**: Development utilities (gitignored, NOT deployed)
- **tests/output/**: Downloaded S3 artifacts (gitignored)
- **Production code**: lambda/, cdk/, config-example/
- Use existing Lambda layers: common, bedrock, dynamodb-operations, validation, requests, web-scraping
- All resources use gensec- prefix and tags
- Python 3.9 runtime for all Lambda functions

## Security Requirements
- Follow AWS security best practices with least privilege IAM
- This system processes sensitive security data - prioritize security, auditability, and least-privilege
- Environment variables must reference CDK-managed resource names
- Support both Strands Agent and direct Bedrock model calls
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
# CDK
cdk/cdk.context.json
cdk/npm-debug.log*
cdk/yarn-debug.log*
cdk/yarn-error.log*
cdk/.nyc_output
cdk/coverage/
cdk/lib/*.js
cdk/lib/*.d.ts
cdk/test/*.js
cdk/test/*.d.ts

# Lambda
lambda/**/*.zip
lambda/**/node_modules/
lambda/**/__pycache__/
lambda/**/*.pyc
lambda/**/.env

# Lambda Layers - Ignore all dependencies, keep only our custom modules
layers/**/python/boto3/
layers/**/python/botocore/
layers/**/python/dateutil/
layers/**/python/urllib3/
layers/**/python/requests/
layers/**/python/beautifulsoup4/
layers/**/python/bs4/
layers/**/python/lxml/
layers/**/python/html5lib/
layers/**/python/certifi/
layers/**/python/charset_normalizer/
layers/**/python/idna/
layers/**/python/jmespath/
layers/**/python/s3transfer/
layers/**/python/soupsieve/
layers/**/python/webencodings/
layers/**/python/six.py
layers/**/python/typing_extensions.py
layers/**/python/bin/
layers/**/python/**/
layers/**/__pycache__/
layers/**/*.pyc
layers/**/*.pyo
layers/**/*.egg-info/
layers/**/build/
layers/**/dist/
# Keep our custom layer modules
!layers/**/python/dynamodb_operations.py
!layers/**/python/json_processing.py
!layers/**/python/s3_operations.py
!layers/**/python/validation.py
!layers/**/python/bedrock_client.py

# AWS
.aws/
*.pem
*.key
.kiro/

# IDE
.vscode/
.idea/
*.swp
*.swo
*~

# OS
.DS_Store
Thumbs.db

# Logs
*.log
logs/

# Temporary files
tmp/
temp/
*.tmp

# Sensitive data
secrets/
*.secret
*.credentials

# compiled resources
**/dist/
cdk/cdk.out/
**/node_modules/

# nodejs
**/package-lock.json

# Working scripts (not part of solution)
tests/output/
lambda-legacy/
Loading