Secure Coding bezeichnet Programmierpraktiken und -richtlinien, die typische, aus der Implementierung resultierende Schwachstellen verhindern. Dazu gehören Validierung und sichere Kodierung von Eingaben (gegen Injection-Angriffe), parametrisierte Datenbank-Abfragen, sichere Speicher- und Datentyp-Behandlung (Bounds Checks, Integer-Overflow-Vermeidung), korrekte Verwendung kryptografischer Bibliotheken (keine selbstgebaute Krypto, sichere Schlüsselverwaltung), Authentifizierung und Autorisierung an jeder Service-Grenze, korrekte Fehlerbehandlung ohne Information Disclosure, sicheres Logging ohne sensitive Daten und sichere Defaults bei jeder Konfiguration.
Eingesetzt werden Secure-Coding-Praktiken in Form von Coding Guidelines (CERT C/C++/Java, OWASP Secure Coding Practices, MISRA für sicherheitskritische Embedded-Software), Linter- und SAST-Werkzeugen (SonarQube, Semgrep, CodeQL, Coverity, Checkmarx), Secure-Code-Review-Praktiken, Pair Programming mit Sicherheits-Fokus, sowie als Bestandteil von Schulungsprogrammen wie SAFECode, SANS Top 25 Most Dangerous Software Errors und OWASP. Sprachspezifisch existieren ergänzende Konventionen — etwa der gezielte Einsatz von "Span<T>" und "unsafe"-freier Code in C#, Owned-Types und Borrow-Checks in Rust, sowie "-Wall -Wextra -Werror" in C/C++.
Der Einsatzzweck und das gelöste Problem liegen in der Vermeidung jener Klassen von Schwachstellen, die seit Jahrzehnten in OWASP-Top-10- und CWE-Top-25-Listen dominieren: Injection, Buffer Overflows, Race Conditions, fehlerhafte Authentifizierung, Cross-Site Scripting, unsichere Deserialisierung, falsche Krypto. Strukturierte Secure-Coding-Praktiken senken die Häufigkeit dieser Fehler systematisch, statt sich auf nachträgliche Tests zu verlassen.
Historisch wurde der Bereich durch Werke wie "Writing Secure Code" (Howard und LeBlanc, Microsoft Press, 2002) und "Secure Coding in C and C++" (Robert Seacord, CERT, 2005) prägend etabliert. Robert Seacords Arbeit am SEI/CERT führte zu der CERT-C/C++-Coding-Standard-Reihe. OWASP hat im Lauf der Jahre umfangreiche Secure-Coding-Cheat-Sheets veröffentlicht, die heute oft als pragmatische Erstreferenz dienen.
Geprägt wurde der Bereich durch Microsoft, CERT/CC, OWASP und eine breite Praktiker-Community. Bei Microsofts Secure-Coding-Initiative im Rahmen des SDL wurde die Verwendung der C-Funktionen "strcpy" und "strcat" systematisch durch ihre sicheren Alternativen "strncpy_s" bzw. "strcpy_s" ersetzt. Microsoft hat dazu eigens den "Banned API List" veröffentlicht und Werkzeuge wie "BinScope" bereitgestellt, die solche Funktionen in Build-Pipelines automatisch flaggen.