Security Devsecops Ssdls Appsec

Cursor-Regel mit DevSecOps/AppSec-Vorgaben für sicheren Code über den gesamten Secure-SDLC.

Original-Beschreibung der Autoren: Cursor rules for secure coding, secret handling, dependency hygiene, authentication, authorization, security testing, and compliance documentation.

Die Regel

---
description: "Cursor rules for secure coding, secret handling, dependency hygiene, authentication, authorization, security testing, and compliance documentation."
globs: ["**/*.py", "**/*.js", "**/*.ts", "**/*.go", "**/*.java", "**/*.rb", "**/*.php", "**/*.cs", "**/*.sh"]
alwaysApply: true
---
# DevSecOps + SSDLC + AppSec Cursor Rule

## General Security Principles
- Never hardcode secrets, credentials, or API keys. Use environment variables or secure vaults for sensitive data.
- Prohibit the inclusion of `.env`, secret config files, or unknown tokens in source control.
- Never log sensitive data, secrets, or session tokens in application logs.
- Validate and sanitize all user input. Escape output in HTML, JS, and SQL contexts.
- Avoid unsafe functions such as `exec`, `eval`, or similar dynamic code execution.

## Database Security
- Use parameterized queries or ORM for all database access. Do not use string concatenation for query building.
- Ensure database users have the least privilege required for their tasks.
- Regularly review and update database access policies.

## Dependency Management
- Only use packages from verified sources.
- Do not add new dependencies without explicit approval and security review.
- Regularly update dependencies and scan for known vulnerabilities (SCA).

## Authentication & Authorization
- Use secure authentication frameworks; never implement custom authentication.
- Store passwords using strong, salted hashes (e.g., Argon2, bcrypt).
- Implement Role-Based Access Control (RBAC) for sensitive operations.
- Enforce the principle of least privilege for APIs and UI actions.

## Secure SDLC Practices
- Integrate Static Application Security Testing (SAST) and Software Composition Analysis (SCA) into the CI pipeline.
- Scan all code for secrets before merging (Secret Scanning).
- Use Infrastructure as Code (IaC) scanning for all infrastructure code.
- Integrate Dynamic Application Security Testing (DAST) in the CD pipeline for deployed applications.
- Enforce Policy as Code (PaC) for automated, version-controlled security policies.

## Monitoring & Feedback
- Enable continuous vulnerability monitoring and alerting.
- Integrate Runtime Application Self-Protection (RASP) and Web Application Firewall (WAF) as appropriate.
- Encourage regular vulnerability assessments and penetration testing.
- Maintain a feedback loop to update rules and prompts based on recurring vulnerabilities.

## Compliance & Documentation
- Align with industry standards (e.g., OWASP Top 10, NIST, ISO 27001).
- Document all security controls and decisions for auditability.

So nutzt du sie

Die Regel kopieren (Button oben) oder als Datei herunterladen und im Projekt unter .cursor/rules/ ablegen — Cursor lädt sie beim nächsten Start automatisch. Ältere Cursor-Versionen lesen alternativ eine einzelne .cursorrules-Datei im Projektstamm; dort einfach den Regel-Text ohne den Kopfblock zwischen den ----Zeilen einfügen.

Der Regel-Text ist englisch — Cursor versteht ihn unabhängig von der Sprache, in der Sie mit dem Editor chatten.

Im Detail

Diese Regel verankert Sicherheitsanforderungen direkt im Code-Generierungsprozess statt sie erst in einer späteren Security-Review nachzuprüfen: Eingabevalidierung, sicherer Umgang mit Secrets, Vermeidung gängiger Schwachstellenklassen wie Injection oder unsichere Deserialisierung sowie Hinweise passend zum jeweiligen Schritt im Secure-SDLC (Design, Implementierung, Test). Für Teams ohne dediziertes AppSec-Team ist das ein praktischer Ersatz für manuell gepflegte Checklisten, weil die Vorgaben automatisch bei jeder Code-Generierung greifen. Wichtig: Die Regel ersetzt kein echtes Security-Review oder Pentesting, sondern reduziert die Grundmenge an offensichtlichen Schwachstellen, die sonst erst durch Scanner oder Audits auffallen würden. Am wertvollsten für Projekte mit Compliance-Anforderungen oder öffentlich erreichbaren Endpunkten.

Praxis-Tipp

Bei “Baue einen Login-Endpunkt” achtet die Regel automatisch auf Dinge wie Rate-Limiting, sichere Passwort-Speicherung und Schutz vor Timing-Angriffen, statt nur die Kernlogik zu liefern.

Lizenz & Quelle

• Lizenz: CC0 1.0
• Quelle: PatrickJS/awesome-cursorrules (GitHub)

Lade …