Merge pull request #960 from cyberstormdotmu/loganaden-strlcpy

Suggest strlcpy in addition to strncpy

Author: david-a-wheeler

docs/Security-Focused-Guide-for-AI-Code-Assistant-Instructions.md

@@ -63,7 +63,7 @@ do not suggest storing sensitive data in plaintext on the device; use the platfo
 When generating github actions or CI/CD pipelines, ensure secrets are stored securely (e.g., using GitHub Secrets or environment variables) and not hard-coded in the workflow files.
 Include steps to run security scans (SAST/DAST) and dependency checks in the CI/CD pipeline to catch vulnerabilities early.
 When generating infrastructure-as-code (IaC) scripts, ensure they follow security best practices (e.g., restrict access to resources, use secure storage for secrets, and validate inputs) and use the latest versions of devops dependencies such as GitHub actions and lock the version to specific SHA.
-In C or C++ code, always use bounds-checked functions (e.g., `strncpy` over `strcpy`), avoid dangerous functions like `gets`, and include buffer size constants to prevent overflow. Enable compiler defenses (stack canaries, fortify source, DEP/NX) in any build configurations you suggest.
+In C or C++ code, always use bounds-checked functions (e.g., `strncpy` or `strlcpy` over `strcpy`), avoid dangerous functions like `gets`, and include buffer size constants to prevent overflow. Enable compiler defenses (stack canaries, fortify source, DEP/NX) in any build configurations you suggest.
 In Rust code, avoid using `unsafe` blocks unless absolutely necessary and document any `unsafe` usage with justification.
 In any memory-safe language, prefer using safe library functions and types; don't circumvent their safety without cause.
 In go code, use the data race detector when building the application.
@@ -133,7 +133,7 @@ Every software runs somewhere – be it a web browser, a cloud platform, an IoT
 
 It's valuable to dedicate individual paragraphs to language-specific security considerations that are relevant to your project. The following section serves as examples, or special cases the AI should handle to highlight unique vulnerabilities or features of that language and how the AI should approach them:
 
-* **C/C++ (Memory-Unsafe Languages):** For languages without automatic memory safety, instruct the AI to be extra cautious with memory management. *"In C or C++ code, always use bounds-checked functions (e.g., `strncpy` over `strcpy`), avoid dangerous functions like `gets`, and include buffer size constants to prevent overflow. Enable compiler defenses (stack canaries, fortify source, DEP/NX) in any build configurations you suggest"*. By giving such instructions, the assistant might prefer safer standard library calls or even suggest modern C++ classes (`std::vector` instead of raw arrays) to reduce manual memory handling. It will also acknowledge when an operation is risky, possibly inserting comments like "// ensure no buffer overflow". [[connordilgren2025a]](#connordilgren2025a) [[neilperry2022c]](#neilperry2022c)
+* **C/C++ (Memory-Unsafe Languages):** For languages without automatic memory safety, instruct the AI to be extra cautious with memory management. *"In C or C++ code, always use bounds-checked functions (e.g., `strncpy` or `strlcpy` over `strcpy`), avoid dangerous functions like `gets`, and include buffer size constants to prevent overflow. Enable compiler defenses (stack canaries, fortify source, DEP/NX) in any build configurations you suggest"*. By giving such instructions, the assistant might prefer safer standard library calls or even suggest modern C++ classes (`std::vector` instead of raw arrays) to reduce manual memory handling. It will also acknowledge when an operation is risky, possibly inserting comments like "// ensure no buffer overflow". [[connordilgren2025a]](#connordilgren2025a) [[neilperry2022c]](#neilperry2022c)
 * **Rust, Go, and Memory-Safe Languages:** If the project involves memory-safe languages (Rust, Go, Java, C#, etc.), you can note that the AI should leverage their safety features. *"In Rust code, avoid using `unsafe` blocks unless absolutely necessary and document any `unsafe` usage with justification".* Memory-safe-by-default languages enforce a lot at compile time, but you should still have the AI follow best practices of those ecosystems. For example, instruct: *"In any memory-safe language, prefer using safe library functions and types; don't circumvent their safety without cause".* If a language offers any tools to verify memory access, direct the AI assistant to use them while building or testing your code. For Example "*In go code, use the data race detector when building the application*". [[openssf2023c]](#openssf2023c)
 * **Python and Dynamic Languages:** Python, JavaScript, and other high-level languages manage memory for you, but come with their own security pitfalls. In your instructions, emphasize things like avoiding exec/eval with untrusted input in Python and being careful with command execution. *"For Python, do not use `exec`/`eval` on user input and prefer safe APIs (e.g., use the `subprocess` module with `shell=False` to avoid shell injection)".* Additionally, mention type checking or the use of linters: *"Follow PEP 8 and use type hints, as this can catch misuse early".* For JavaScript/TypeScript, you might add: *"When generating Node.js code, use prepared statements for database queries (just like any other language) and encode any data that goes into HTML to prevent XSS".* These instructions incorporate known best practices (like those from OWASP cheat sheets) directly into the AI's behavior. [[haoyan2025c]](#haoyan2025c)
 * **Java/C# and Enterprise Languages:** In languages often used for large applications, you might focus on frameworks and configurations. *"For Java, when suggesting web code (e.g., using Spring), ensure to use built-in security annotations and avoid old, vulnerable libraries (e.g., use `BCryptPasswordEncoder` rather than writing a custom password hash)".* For C#, similarly: *"Use .NET's cryptography and identity libraries instead of custom solutions".* Also instruct about managing object deserialization (both Java and C# have had vulnerabilities in this area): *"Never suggest turning off security features like XML entity security or type checking during deserialization".* These language-specific notes guide the AI to incorporate the well-known secure patterns of each ecosystem. [[neilperry2022d]](#neilperry2022d)