Jak zabezpieczyć cykl życia rozwoju oprogramowania przy użyciu AI

We are building a [feature/system description] that handles [data types].
Our compliance scope includes ISO 27001:2022 and SOC 2 Type II.

Generate security requirements for this feature covering:
- Authentication and session management
- Input validation and output encoding
- Data protection (at rest and in transit)
- Logging and audit trail requirements
- Error handling and information disclosure prevention
- Access control and authorization

For each requirement, provide: the requirement statement, acceptance criteria,
the ISO 27001 Annex A control it satisfies, and the OWASP category it addresses.

Perform a STRIDE threat analysis for the following system architecture:
[Describe components, data flows, trust boundaries, external integrations]

For each identified threat:
- Classify by STRIDE category (Spoofing, Tampering, Repudiation,
  Information Disclosure, Denial of Service, Elevation of Privilege)
- Assess severity (Critical/High/Medium/Low)
- Map to relevant OWASP Top 10 category
- Recommend specific mitigations
- Reference the ISO 27001:2022 Annex A control that addresses this threat

Output as a structured threat model document suitable for design review.

Review this system architecture against ISO 27001 A.8.27 secure engineering
principles and OWASP Application Security Verification Standard (ASVS) Level 2:
[Paste or describe architecture]

Evaluate:
- Defense in depth implementation
- Least privilege in service-to-service communication
- Secure defaults and fail-safe design
- Input validation at trust boundaries
- Separation of concerns and environment isolation (A.8.31)
- Cryptographic controls for data protection

Identify gaps and recommend specific changes with implementation priority.

Create a secure coding standard for [language/framework, e.g., "Python 3.x with
Django 5.x and PostgreSQL"]. Structure the standard as follows:

1. Input validation rules (OWASP ASVS V5)
2. Output encoding requirements (OWASP ASVS V6)
3. Authentication implementation patterns (OWASP ASVS V2)
4. Session management requirements (OWASP ASVS V3)
5. Access control implementation (OWASP ASVS V4)
6. Cryptographic practices (OWASP ASVS V6)
7. Error handling and logging (OWASP ASVS V7, V8)
8. Data protection patterns (OWASP ASVS V9)
9. Dependency management and SCA requirements
10. Secrets handling (no hardcoded credentials, environment variable usage)

For each section, provide: specific code examples showing the correct pattern,
anti-patterns to avoid, and automated tooling that can enforce the rule.
Map each section to ISO 27001 A.8.28 sub-requirements.

Create a developer security checklist based on the OWASP Top 10 (2021)
tailored for [your tech stack]. For each OWASP category:

- A01:2021 Broken Access Control
- A02:2021 Cryptographic Failures
- A03:2021 Injection
- A04:2021 Insecure Design
- A05:2021 Security Misconfiguration
- A06:2021 Vulnerable and Outdated Components
- A07:2021 Identification and Authentication Failures
- A08:2021 Software and Data Integrity Failures
- A09:2021 Security Logging and Monitoring Failures
- A10:2021 Server-Side Request Forgery

Provide 3-5 actionable checklist items specific to [framework].
Include the ISO 27001 control reference for each category.
Format as a printable one-page reference card.

Create a secure coding training module for [language/framework] developers. Include:
- Common vulnerability patterns with real-world examples (sanitized)
- Hands-on exercises: vulnerable code snippets to identify and fix
- Correct implementation patterns for our tech stack
- How to use our security tooling ([SAST tool], [SCA tool], [secrets scanner])
- How secure coding maps to our compliance requirements (ISO 27001 A.8.28, SOC 2 CC8.1)

Target audience: mid-level developers. Duration: 60 minutes.
Include a quiz with 10 questions to verify comprehension.

Create a security-focused code review checklist for [language/framework]
pull requests. Organize by risk category:

Authentication and Authorization:
- Are authorization checks present on all endpoints/routes?
- Is authentication state validated server-side?
- Are role checks implemented at the function level, not just UI?

Input Handling:
- Is all user input validated against an allowlist?
- Are parameterized queries used for all database operations?
- Is output properly encoded for the rendering context (HTML, JSON, URL)?

Data Protection:
- Are sensitive fields excluded from logs and error messages?
- Is PII encrypted at rest and masked in non-production environments?
- Are API responses filtered to return only necessary fields?

Dependency and Configuration:
- Do new dependencies have known vulnerabilities (CVE check)?
- Are secrets managed via environment variables or vault, never hardcoded?
- Are security headers configured for new endpoints?

Map each checklist item to OWASP Top 10 categories and ISO 27001 A.8.28/A.8.29.

Document the top 15 vulnerability patterns that code reviewers should look for
in [language/framework] codebases. For each pattern:

- Vulnerability name and CWE identifier
- What it looks like in code (example snippet)
- Why it is dangerous (exploitation scenario)
- How to fix it (corrected code snippet)
- How SAST tools detect it (rule name in [your SAST tool])
- OWASP Top 10 mapping
- ISO 27001 control reference

Prioritize by prevalence in [language] applications.
Include patterns for: injection, broken access control, cryptographic failures,
SSRF, mass assignment, insecure deserialization, and path traversal.

Create a Security Code Review Procedure document for ISO 27001 A.8.29 and
SOC 2 CC8.1 compliance. Include:

1. Purpose and scope
2. Roles: who performs security reviews (developer, security champion, AppSec engineer)
3. Criteria for mandatory security review (e.g., auth changes, new API endpoints,
   data model changes, dependency updates, infrastructure-as-code changes)
4. Review process steps with SLA timelines
5. Security review checklist reference
6. Escalation process for findings
7. Documentation requirements (what gets recorded in the PR)
8. Metrics to track (review coverage, findings per review, time to resolve)
9. Exception process for emergency changes
10. Evidence retention for audit purposes

Context: our team uses [Git platform], [CI/CD tool], and [issue tracker].

Design a vulnerability management program for a [organization description]
development team. Include:

1. Scope: application code, dependencies, container images, IaC, cloud configuration
2. Discovery: tools and scanning cadence for each scope area
   - SAST: [tool] on every PR
   - SCA: [tool] daily dependency scans
   - DAST: [tool] weekly against staging
   - Container scanning: [tool] on image build
   - Cloud configuration: [tool] continuous
3. Triage criteria using CVSS base score + exploitability + asset criticality
4. Severity classification aligned with our risk appetite
5. SLA timelines by severity:
   - Critical (CVSS 9.0-10.0): remediate within [X] hours
   - High (CVSS 7.0-8.9): remediate within [X] days
   - Medium (CVSS 4.0-6.9): remediate within [X] days
   - Low (CVSS 0.1-3.9): remediate within [X] days
6. Remediation workflow with ticket creation, assignment, verification
7. Exception and risk acceptance process with required approvals
8. Metrics and KPIs (MTTR by severity, SLA compliance rate, vulnerability backlog trend)
9. Reporting cadence (weekly operational, monthly leadership, quarterly board)
10. Audit evidence requirements per ISO 27001 A.8.8 and SOC 2 CC7.1

Map the program to NIST SP 800-40 (Guide to Enterprise Patch Management).

Create a vulnerability triage and prioritization matrix that considers:
- CVSS base score
- Exploitability (is there a public exploit? Is it actively exploited per CISA KEV?)
- Asset criticality (production vs. staging, internet-facing vs. internal)
- Data sensitivity (PII, financial data, authentication credentials)
- Compensating controls in place (WAF, network segmentation, access restrictions)

Output a scoring model with worked examples showing how the same CVE
gets different effective priority depending on context.
Include decision criteria for: immediate remediation, scheduled remediation,
risk acceptance, and false positive disposition.

For the following vulnerability finding, generate developer remediation guidance:
- CVE/CWE: [identifier]
- Affected component: [library, code module, configuration]
- Current version: [version]
- Our tech stack: [language, framework, deployment platform]

Provide:
1. Plain-language explanation of the vulnerability and its risk
2. Specific fix (code change, version upgrade, configuration change)
3. Testing steps to verify the fix works
4. Regression considerations
5. Timeline estimate for remediation effort

Create a Change Management Procedure for software deployments that satisfies
ISO 27001 A.8.25, A.8.31, A.8.32 and SOC 2 CC8.1. Include:

1. Change classification (standard, normal, emergency) with criteria for each
2. Change request documentation requirements
3. Risk assessment for each change (impact analysis, rollback feasibility)
4. Approval workflow:
   - Standard changes: pre-approved, automated deployment
   - Normal changes: peer review + team lead approval
   - Emergency changes: single approver + retrospective review within 48 hours
5. Testing requirements by change type (unit, integration, security, UAT)
6. Deployment process with pre-deployment and post-deployment checklists
7. Environment promotion path (dev → staging → production) per A.8.31
8. Rollback procedures and criteria for triggering rollback
9. Post-deployment verification steps
10. Evidence retention (approval records, test results, deployment logs)
11. Emergency change retrospective process
12. Metrics: change success rate, rollback frequency, mean time to deploy

Context: we use [Git platform], [CI/CD tool], and deploy to [infrastructure].
Our team has [X] developers and deploys [frequency].

Create deployment checklists for three scenarios:

1. Standard deployment (pre-approved, low-risk):
   - Pre-deployment: CI pipeline green, security scans passed, feature flags configured
   - Deployment: automated via pipeline, health checks passing
   - Post-deployment: smoke tests, monitoring dashboards checked, stakeholders notified

2. High-risk deployment (database migrations, auth changes, infrastructure changes):
   - Pre-deployment: security review completed, rollback plan documented,
     backup verified, maintenance window scheduled, on-call notified
   - Deployment: manual approval gate, staged rollout, real-time monitoring
   - Post-deployment: extended monitoring period, regression test suite,
     security scan of production, stakeholder sign-off

3. Emergency deployment (security hotfix, critical production issue):
   - Pre-deployment: single approver authorization, minimal viable testing
   - Deployment: direct to production with monitoring
   - Post-deployment: full retrospective within 48 hours, complete test suite
     run, change request documented retroactively

Map each checklist item to ISO 27001 A.8.32 and SOC 2 CC8.1 evidence requirements.

Create a rollback plan template for software deployments. Include:

1. Rollback trigger criteria (error rate threshold, latency increase,
   failed health checks, security incident)
2. Decision authority (who can authorize rollback)
3. Rollback procedures by deployment type:
   - Application code: container image revert, blue-green switch, feature flag disable
   - Database migration: backward-compatible migration strategy, point-in-time recovery
   - Infrastructure change: Terraform state rollback, manual revert steps
   - Configuration change: config management revert, cache invalidation
4. Verification steps after rollback
5. Communication plan (internal team, stakeholders, customers if applicable)
6. Root cause analysis requirements
7. Documentation for audit trail

Context: we deploy using [deployment strategy] on [infrastructure].

Create a Secure Software Development Lifecycle Policy for [organization name/type]
that addresses ISO 27001:2022 controls A.8.25 through A.8.31 and SOC 2 CC8.1.
Include: purpose and scope, roles and responsibilities (development team, security
team, management), security activities at each SDLC phase (requirements, design,
implementation, testing, deployment, maintenance), mandatory security gates,
training requirements, outsourced development requirements (A.8.30), environment
separation standards (A.8.31), exception handling, and policy review schedule.
Our tech stack is [languages, frameworks, cloud provider]. We have [X] developers
and release [frequency].

Perform a STRIDE threat model for the following new feature: [describe feature,
data flows, user interactions, and external integrations]. Identify threats at
each trust boundary, rate severity using DREAD or CVSS, recommend mitigations
mapped to OWASP ASVS controls and ISO 27001 Annex A controls. Output as a
structured document I can attach to our design review record for A.8.26 compliance.

Design a security testing strategy for our upcoming release that includes
[describe major changes]. Cover SAST, DAST, SCA, and manual penetration testing
requirements. Define pass/fail criteria for each test type, identify which tests
block deployment versus which generate advisory findings, and map the strategy
to ISO 27001 A.8.29 and SOC 2 CC8.1. Include estimated effort and recommended
tools for our [tech stack] environment.

Create vulnerability remediation SLA definitions for our development team that
satisfy ISO 27001 A.8.8 and SOC 2 CC7.1. Define severity levels using CVSS
scores contextualized by asset criticality and exploitability. Set remediation
timelines for each severity level. Include the exception/risk acceptance process
requiring [approval authority] sign-off, metrics we should track to demonstrate
compliance, and a reporting template for monthly leadership review.
Our environment: [describe infrastructure, application types, team size].

Write an Emergency Change Procedure for critical production issues and security
hotfixes. Address: who can authorize an emergency change, minimum testing
requirements before deployment, how to document the change retroactively within
48 hours, required retrospective process, and how emergency changes are reported
in our SOC 2 CC8.1 evidence package. Include a decision flowchart for determining
whether a situation qualifies as an emergency versus a normal expedited change.
Our deployment infrastructure: [describe CI/CD pipeline and hosting].

I will describe our current software development practices. Assess them against
ISO 27001:2022 controls A.8.25 through A.8.31, SOC 2 CC8.1, and NIST SP 800-218
SSDF practices. For each control, rate our maturity (Not Implemented, Partially
Implemented, Fully Implemented), identify specific gaps, and recommend remediation
actions with priority and estimated effort.

Our current practices: [describe your SDLC phases, tools, review processes,
testing approach, deployment process, and environment setup].