sinapse-ai 1.0.0

package/squad-cybersecurity/tasks/code-security-review.md

@@ -0,0 +1,65 @@
+---
+task: "code-security-review"
+responsavel: "penetration-tester"
+responsavel_type: "agent"
+atomic_layer: true
+elicit: false
+Entrada:
+  - campo: code_files
+    tipo: list
+    origem: "repository"
+    obrigatorio: true
+  - campo: language
+    tipo: text
+    origem: "auto-detect or user input"
+    obrigatorio: true
+Saida:
+  - campo: security_review
+    tipo: document
+    destino: "development team"
+Checklist:
+  - "[ ] Identify language-specific vulnerability patterns"
+  - "[ ] Check for injection vulnerabilities"
+  - "[ ] Check for authentication/authorization flaws"
+  - "[ ] Check for cryptographic issues"
+  - "[ ] Check for sensitive data handling"
+  - "[ ] Check for dependency vulnerabilities"
+  - "[ ] Provide specific fix recommendations"
+---
+
+# Code Security Review
+
+## Objective
+
+Perform a security-focused code review to identify vulnerabilities, insecure patterns, and security anti-patterns. Provide specific, line-level remediation guidance.
+
+## Inputs
+
+- Source code files or pull request diff
+- Programming language and framework
+- Application context (what the code does)
+
+## Steps
+
+1. **Understand context** — What does this code do? What data does it handle? What trust boundaries does it cross?
+
+2. **Injection analysis** — SQL injection, command injection, XSS, SSTI, path traversal. Check all user input handling paths.
+
+3. **Authentication review** — Password handling, session management, token generation, credential storage, MFA implementation.
+
+4. **Authorization review** — Access control checks, IDOR patterns, privilege boundary enforcement, role validation.
+
+5. **Cryptography review** — Algorithm selection, key management, random number generation, hashing (passwords vs data integrity), TLS configuration.
+
+6. **Sensitive data handling** — PII handling, logging of sensitive data, error message exposure, secrets in code, environment variable handling.
+
+7. **Dependency analysis** — Known vulnerable dependencies, outdated libraries, license issues, supply chain risks.
+
+8. **Language-specific checks** — Deserialization (Java, Python, PHP), prototype pollution (JavaScript), memory safety (C/C++), type confusion.
+
+## Quality Gates
+
+- Every finding references specific code lines
+- Severity is assessed in application context
+- Fix recommendations include code examples
+- False positives are documented with reasoning

package/squad-cybersecurity/tasks/communication-plan-incident.md

@@ -0,0 +1,227 @@
+---
+task: communication-plan-incident
+responsavel: "incident-responder"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: incident_severity
+    tipo: enum
+    origem: "incident-triage or user input"
+    obrigatorio: true
+    valores: ["SEV-1", "SEV-2", "SEV-3", "SEV-4"]
+  - campo: stakeholders
+    tipo: list
+    origem: "user input"
+    obrigatorio: true
+  - campo: regulatory_requirements
+    tipo: list
+    origem: "user input"
+    obrigatorio: false
+
+Saida:
+  - campo: communication_plan
+    tipo: document
+    destino: "IR team, communications, legal, stakeholders"
+
+Checklist:
+  - "[ ] Identify all communication audiences"
+  - "[ ] Define communication channels per audience"
+  - "[ ] Create message templates per severity"
+  - "[ ] Establish approval workflows"
+  - "[ ] Document regulatory notification requirements"
+  - "[ ] Plan media response strategy"
+  - "[ ] Design status update cadence"
+  - "[ ] Validate with legal and communications"
+---
+
+# Task: Crisis Communication Plan for Security Incidents
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Rapid (incident-responder)
+- **Complexity:** Standard
+
+## Objective
+
+Create a crisis communication plan for security incidents that defines who communicates what, to whom, when, and through which channels. The plan ensures consistent, timely, and legally appropriate communication during incidents while preserving investigation integrity.
+
+> **CONFIDENTIALITY WARNING:** Incident communication plans contain sensitive procedures and contact information. Distribution should be limited to authorized personnel. Premature or inaccurate public disclosure can cause significant harm.
+
+## Pre-Conditions
+
+- Incident response plan exists
+- Legal counsel available for review
+- Communications/PR team identified
+- Executive sponsor designated
+- Regulatory notification requirements understood
+
+## Inputs
+
+- Incident severity level (SEV-1 through SEV-4)
+- Stakeholder list (internal and external)
+- Regulatory notification requirements
+- Organization's brand/communications guidelines
+- Previous incident communication experiences
+
+## Steps
+
+### 1. Map Communication Audiences
+Identify all audiences who may need to be informed:
+
+| Audience | When Notified | Who Communicates | Channel |
+|----------|-------------|-----------------|---------|
+| IR Team | Immediately | IR Lead | Secure chat + phone |
+| IT Operations | Immediately | IR Lead | Secure chat |
+| Executive Team | Within 1h (SEV-1) | IR Lead/CISO | Phone + email |
+| Legal Counsel | Within 1h (SEV-1/2) | IR Lead | Phone |
+| Board of Directors | Within 24h (SEV-1) | CISO/CEO | Secure brief |
+| Employees | As needed | HR/Comms | Internal comms |
+| Customers | Per legal guidance | Comms team | Email/portal |
+| Regulators | Per compliance req | Legal | Official channels |
+| Media | If contacted | PR/Comms | Prepared statement |
+| Partners/Vendors | If affected | Account managers | Phone + email |
+| Law Enforcement | If criminal activity | Legal | Official channels |
+
+### 2. Create Internal Communication Templates
+Draft templates for internal audiences:
+
+**Initial Notification (SEV-1/2):**
+```
+SECURITY INCIDENT NOTIFICATION — [SEVERITY]
+Time: [timestamp]
+Status: [Active/Contained/Resolved]
+Summary: [Brief factual description]
+Impact: [Known impact]
+Actions Taken: [Current response actions]
+Your Role: [What the recipient should do]
+Next Update: [When to expect the next update]
+Contact: [IR Lead contact for questions]
+CONFIDENTIAL — Do not share outside authorized personnel
+```
+
+**Status Update Template:**
+```
+INCIDENT UPDATE #[N] — [SEVERITY]
+Time: [timestamp]
+Status Change: [What changed since last update]
+Current Status: [Overall status]
+Impact Update: [Updated impact assessment]
+Actions: [Actions taken since last update]
+Next Steps: [Planned actions]
+Next Update: [When]
+```
+
+### 3. Create External Communication Templates
+Draft templates for external audiences (requires legal review):
+
+**Customer Notification:**
+- What happened (factual, no speculation)
+- What data was affected (if known)
+- What we are doing about it
+- What customers should do
+- Where to get more information
+- Apology and commitment to improvement
+
+**Regulatory Notification:**
+- Organization identification
+- Nature of the incident
+- Data categories affected
+- Number of individuals affected (if applicable)
+- Measures taken and proposed
+- Contact point for the authority
+
+### 4. Define Approval Workflows
+Establish who must approve communications before release:
+
+| Communication Type | Draft By | Reviewed By | Approved By |
+|-------------------|----------|-------------|-------------|
+| Internal — IR team | IR Lead | — | IR Lead |
+| Internal — executives | CISO | Legal | CEO |
+| Internal — all employees | Comms | Legal, HR | CISO |
+| External — customers | Comms | Legal, CISO | CEO |
+| External — regulators | Legal | CISO | CEO |
+| External — media | PR | Legal, CISO | CEO |
+
+### 5. Establish Update Cadence
+Define how frequently updates are provided:
+
+| Severity | Internal Updates | Executive Updates | External Updates |
+|----------|-----------------|-------------------|-----------------|
+| SEV-1 | Every 2 hours | Every 4 hours | Per legal guidance |
+| SEV-2 | Every 4 hours | Daily | If needed |
+| SEV-3 | Daily | Weekly | Unlikely |
+| SEV-4 | As needed | As needed | No |
+
+### 6. Design Media Response Strategy
+Prepare for media inquiries:
+- Designated spokesperson (trained in crisis communications)
+- Holding statement (ready before any incident)
+- Q&A document with anticipated questions
+- Social media monitoring and response plan
+- "No comment" alternatives that maintain credibility
+
+### 7. Define Information Security During Communication
+Protect investigation integrity:
+- What information can be shared at each stage
+- What must NOT be disclosed (investigation details, attribution)
+- Secure communication channels for incident discussions
+- Information classification for incident documents
+- Restrictions on social media by employees
+
+### 8. Document Regulatory Notification Timelines
+Create a compliance checklist:
+| Regulation | Trigger | Deadline | Recipient | Required Info |
+|-----------|---------|----------|-----------|--------------|
+| GDPR | Personal data breach | 72 hours | DPA | Per Article 33 |
+| HIPAA | PHI breach | 60 days | HHS/OCR | Per Breach Rule |
+| PCI DSS | Card data compromise | Immediate | Acquirer, brands | Per PCI IR |
+| SEC (if public) | Material cybersecurity incident | 4 business days | SEC | Form 8-K |
+
+### 9. Create Communication Toolkit
+Assemble ready-to-use resources:
+- Contact list (internal and external, with backups)
+- Template library (all message types)
+- Approval workflow chart
+- Regulatory notification checklist
+- Media holding statement
+- FAQ document (updateable)
+- Secure communication channel setup guide
+
+### 10. Test and Validate
+Validate the communication plan:
+- Include communication as a component of tabletop exercises
+- Test notification chains (can you reach everyone in 1 hour?)
+- Verify secure communication channels work
+- Review with legal counsel annually
+- Update after every significant incident
+
+## Output
+
+```yaml
+communication_plan:
+  date: ""
+  author: "Rapid (incident-responder)"
+
+  audiences: []
+  templates:
+    internal: []
+    external: []
+  approval_workflows: []
+  update_cadence: {}
+  regulatory_notifications: []
+  media_strategy: {}
+  toolkit_contents: []
+```
+
+## Quality Criteria
+
+- [ ] All communication audiences identified with channels
+- [ ] Templates created for each audience and severity
+- [ ] Approval workflows defined and practical
+- [ ] Regulatory notification requirements documented with deadlines
+- [ ] Media response strategy includes trained spokesperson
+- [ ] Information security controls during communication defined
+- [ ] Communication plan tested in exercises
+- [ ] Legal counsel has reviewed all external templates

package/squad-cybersecurity/tasks/compliance-gap-analysis.md

@@ -0,0 +1,64 @@
+---
+task: "compliance-gap-analysis"
+responsavel: "compliance-officer"
+responsavel_type: "agent"
+atomic_layer: true
+elicit: true
+Entrada:
+  - campo: framework
+    tipo: enum
+    origem: "user input"
+    obrigatorio: true
+    valores: ["soc2", "iso27001", "gdpr", "lgpd", "hipaa", "pci-dss", "nist-csf"]
+  - campo: current_controls
+    tipo: document
+    origem: "user input"
+    obrigatorio: false
+Saida:
+  - campo: gap_analysis_report
+    tipo: document
+    destino: "stakeholders"
+Checklist:
+  - "[ ] Identify applicable framework requirements"
+  - "[ ] Inventory current security controls"
+  - "[ ] Map controls to framework requirements"
+  - "[ ] Identify gaps (missing or partial controls)"
+  - "[ ] Assess gap severity and risk"
+  - "[ ] Produce remediation roadmap with priorities"
+---
+
+# Compliance Gap Analysis
+
+## Objective
+
+Perform a structured gap analysis against a specific regulatory or security framework. Map current controls to framework requirements, identify gaps, and produce a prioritized remediation roadmap.
+
+## Inputs
+
+- Target compliance framework
+- Description of current security controls (or will be assessed)
+- Organization context (industry, size, data types, geography)
+- Previous audit findings (if any)
+
+## Steps
+
+1. **Scope the framework** — Identify which sections/requirements of the framework are applicable based on organization context. Document exclusions with justification.
+
+2. **Inventory controls** — Document existing security controls: policies, procedures, technical controls, monitoring capabilities, training programs.
+
+3. **Map controls to requirements** — For each framework requirement, identify which existing controls address it. Rate as: Fully Implemented, Partially Implemented, or Not Implemented.
+
+4. **Identify gaps** — For Partially and Not Implemented requirements, document what is missing and what is needed.
+
+5. **Risk-assess gaps** — Rate each gap by: regulatory risk (mandatory vs recommended), security risk (exploitability and impact), and remediation effort.
+
+6. **Produce roadmap** — Create a phased remediation plan: Phase 1 (critical gaps, 0-3 months), Phase 2 (high gaps, 3-6 months), Phase 3 (medium gaps, 6-12 months).
+
+7. **Evidence mapping** — For each implemented control, specify what evidence demonstrates compliance. This prepares for audit.
+
+## Quality Gates
+
+- Every applicable framework requirement must be assessed
+- Gaps must be prioritized by risk, not just listed
+- Remediation roadmap must include effort estimates
+- Evidence requirements must be defined for implemented controls

package/squad-cybersecurity/tasks/container-security-hardening.md

@@ -0,0 +1,199 @@
+---
+task: container-security-hardening
+responsavel: "cloud-security-engineer"
+responsavel_type: Agent
+atomic_layer: Task
+elicit: true
+
+Entrada:
+  - campo: container_platform
+    tipo: enum
+    origem: "user input"
+    obrigatorio: true
+    valores: ["Docker", "Kubernetes", "ECS", "AKS", "GKE", "multi-platform"]
+  - campo: current_setup
+    tipo: text
+    origem: "user input"
+    obrigatorio: true
+
+Saida:
+  - campo: container_hardening_plan
+    tipo: document
+    destino: "dev team, devops, stakeholders"
+
+Checklist:
+  - "[ ] Assess current container security baseline"
+  - "[ ] Review image build pipeline security"
+  - "[ ] Evaluate runtime security controls"
+  - "[ ] Assess orchestrator configuration"
+  - "[ ] Review network policies"
+  - "[ ] Check secrets management"
+  - "[ ] Validate supply chain security"
+  - "[ ] Produce hardening implementation plan"
+---
+
+# Task: Container Security Hardening
+
+## Metadata
+- **Squad:** squad-cybersecurity
+- **Agent:** Nimbus (cloud-security-engineer)
+- **Complexity:** Complex
+
+## Objective
+
+Assess and harden container infrastructure security across the build, deploy, and runtime phases. Cover image security, orchestrator configuration, network policies, secrets management, runtime protection, and supply chain integrity for Docker, Kubernetes, and managed container services.
+
+> **DEFENSIVE HARDENING:** This task focuses on strengthening container security through configuration improvements and best practices. All assessments use authorized access only.
+
+## Pre-Conditions
+
+- Access to container platform (read access minimum)
+- Understanding of current container architecture
+- Knowledge of deployed workloads
+- Container security baseline (CIS Docker/Kubernetes Benchmark)
+
+## Inputs
+
+- Container platform (Docker, Kubernetes, ECS, AKS, GKE)
+- Current container setup description
+- Dockerfiles and container manifests (if available)
+- CI/CD pipeline configuration
+- Current security controls in place
+
+## Steps
+
+### 1. Assess Current Security Baseline
+Evaluate against CIS Benchmarks:
+| Category | CIS Control | Status | Priority |
+|----------|------------|--------|----------|
+| Host configuration | Docker daemon hardening | | |
+| Image configuration | Trusted base images | | |
+| Runtime configuration | Container privileges | | |
+| Orchestrator | K8s API security | | |
+| Network | Network policies | | |
+| Secrets | Secret management | | |
+
+### 2. Image Build Security
+Harden the image build pipeline:
+- Use minimal base images (distroless, Alpine)
+- Pin image versions (no :latest in production)
+- Scan images for vulnerabilities (Trivy, Snyk, Grype)
+- Implement multi-stage builds to reduce attack surface
+- Remove unnecessary packages and tools
+- Set non-root USER directive
+- Add HEALTHCHECK directive
+- Sign images (Cosign, Notary)
+
+### 3. Image Supply Chain Security
+Verify image provenance:
+- Trusted base image registry
+- Image signing and verification
+- SBOM generation for container images
+- Vulnerability scanning in CI/CD pipeline
+- Admission controllers to block unsigned/unscanned images
+- Private registry configuration and access control
+
+### 4. Runtime Security Configuration
+Harden container runtime:
+| Control | Description | Implementation |
+|---------|-----------|---------------|
+| Read-only root filesystem | Prevent runtime modifications | `readOnlyRootFilesystem: true` |
+| No privilege escalation | Block setuid/setgid | `allowPrivilegeEscalation: false` |
+| Drop capabilities | Remove unneeded Linux capabilities | `drop: [ALL]` |
+| Non-root user | Run as non-root | `runAsNonRoot: true` |
+| Resource limits | Prevent resource abuse | CPU/memory limits |
+| Seccomp profiles | Restrict syscalls | Default or custom profile |
+| AppArmor/SELinux | Mandatory access control | Enforce profiles |
+
+### 5. Kubernetes Security (if applicable)
+Harden orchestrator configuration:
+- API server authentication and authorization (RBAC)
+- Admission controllers (PodSecurity, OPA/Gatekeeper)
+- etcd encryption at rest
+- Audit logging enabled
+- Node authorization
+- Service account token management
+- Pod Security Standards enforcement
+
+### 6. Network Policies
+Implement network segmentation:
+- Default deny all ingress/egress
+- Allow only required communication paths
+- Isolate namespaces
+- Restrict pod-to-pod communication
+- Egress control for internet access
+- Service mesh security (mTLS)
+
+### 7. Secrets Management
+Secure sensitive data:
+- No secrets in Dockerfiles or images
+- External secrets management (Vault, AWS Secrets Manager)
+- Encrypted secrets at rest (K8s secrets encryption)
+- Secret rotation automation
+- Access control for secrets
+- Audit logging for secret access
+
+### 8. Monitoring and Detection
+Implement runtime security monitoring:
+- Container behavior monitoring (Falco, Sysdig)
+- Image drift detection
+- Anomalous process execution alerting
+- Network anomaly detection
+- File integrity monitoring
+- Container escape attempt detection
+
+### 9. CI/CD Pipeline Security
+Secure the container deployment pipeline:
+- Pipeline access control
+- Image scanning gates (block critical CVEs)
+- Policy-as-code enforcement
+- Deployment approval workflows
+- Rollback procedures
+- Artifact integrity verification
+
+### 10. Produce Hardening Implementation Plan
+Compile findings into a phased implementation plan prioritized by risk and effort.
+
+## Output
+
+```yaml
+container_hardening_plan:
+  platform: ""
+  date: ""
+  author: "Nimbus (cloud-security-engineer)"
+
+  baseline_assessment:
+    cis_compliance: ""
+    critical_findings: 0
+    high_findings: 0
+
+  hardening_actions:
+    - category: ""
+      action: ""
+      priority: "[P1/P2/P3]"
+      effort: "[low/medium/high]"
+      implementation: ""
+      verification: ""
+
+  phases:
+    phase_1_immediate:
+      actions: []
+      timeline: ""
+    phase_2_short_term:
+      actions: []
+      timeline: ""
+    phase_3_long_term:
+      actions: []
+      timeline: ""
+```
+
+## Quality Criteria
+
+- [ ] CIS Benchmark assessment completed
+- [ ] Image build security reviewed
+- [ ] Supply chain integrity controls assessed
+- [ ] Runtime security configuration evaluated
+- [ ] Network policies reviewed or recommended
+- [ ] Secrets management assessed
+- [ ] Implementation plan phased by priority
+- [ ] Hardening actions include verification steps

package/squad-cybersecurity/tasks/container-security-review.md

@@ -0,0 +1,71 @@
+---
+task: "container-security-review"
+responsavel: "cloud-security-engineer"
+responsavel_type: "agent"
+atomic_layer: true
+elicit: true
+Entrada:
+  - campo: container_environment
+    tipo: text
+    origem: "user input"
+    obrigatorio: true
+  - campo: dockerfiles
+    tipo: list
+    origem: "repository"
+    obrigatorio: false
+  - campo: k8s_manifests
+    tipo: list
+    origem: "repository"
+    obrigatorio: false
+Saida:
+  - campo: container_security_report
+    tipo: document
+    destino: "development team, stakeholders"
+Checklist:
+  - "[ ] Review Dockerfile security (base images, user, secrets)"
+  - "[ ] Scan container images for vulnerabilities"
+  - "[ ] Review Kubernetes RBAC configuration"
+  - "[ ] Check Pod Security Standards enforcement"
+  - "[ ] Review network policies"
+  - "[ ] Assess secrets management"
+  - "[ ] Check admission controllers"
+  - "[ ] Review supply chain security"
+---
+
+# Container Security Review
+
+## Objective
+
+Assess security of container images, Dockerfiles, Kubernetes configurations, and container runtime settings. Cover the full container lifecycle from build to runtime.
+
+## Inputs
+
+- Container environment description (Docker, Kubernetes, ECS, etc.)
+- Dockerfiles and build configurations
+- Kubernetes manifests (deployments, services, RBAC, network policies)
+- Registry configuration
+
+## Steps
+
+1. **Image security** — Review base images (official, minimal, up-to-date), scan for CVEs, check for hardcoded secrets, verify non-root user, assess image size and layers.
+
+2. **Dockerfile review** — Check for security anti-patterns: running as root, ADD vs COPY, secrets in build args, unnecessary packages, missing health checks.
+
+3. **Kubernetes RBAC** — Review cluster roles, role bindings, service account permissions. Identify overprivileged service accounts and unnecessary cluster-admin bindings.
+
+4. **Pod Security** — Check for privileged containers, host namespace sharing, capabilities, seccomp/AppArmor profiles, read-only root filesystem.
+
+5. **Network Policies** — Verify pod-to-pod communication is restricted by default. Check for missing network policies that allow unrestricted lateral movement.
+
+6. **Secrets management** — Verify secrets are not in environment variables or ConfigMaps in plain text. Check for external secrets management (Vault, Sealed Secrets, External Secrets Operator).
+
+7. **Admission control** — Verify policy enforcement (OPA/Gatekeeper, Kyverno) is in place to prevent insecure deployments.
+
+8. **Supply chain** — Check image signing, SBOM generation, registry access controls, and CI/CD pipeline security.
+
+## Quality Gates
+
+- All Dockerfiles reviewed for security anti-patterns
+- Images scanned for known vulnerabilities
+- Kubernetes RBAC reviewed for least privilege
+- Network policies assessed for default-deny enforcement