add extra explanation for the security flavorz

commjoen · commjoen · commit efb1ebfc512a · 2025-07-09T09:24:52.000+02:00
diff --git a/cursor/rules/conversation-log.txt b/cursor/rules/conversation-log.txt
@@ -42,3 +42,6 @@ Assistant: Added @SuppressFBWarnings annotation to getActualSecret with justific
 
 User: can you update the conversation history file?
 Assistant: (this file)
+
+User: can you update the materials in  @/rules please?
+Assistant: Updated project-specification.mdc to include security best practices and real-world requirements from challenge56_reason.adoc for future reference.
diff --git a/cursor/rules/project-specification.mdc b/cursor/rules/project-specification.mdc
@@ -170,3 +170,26 @@ To speed up challenge creation, follow these steps:
 ---
 
 **Tip:** Use the most recent challenge as a template for new ones to save time and ensure consistency.
+
+---
+
+## Security Requirements and Best Practices (for Real Projects)
+
+In real projects, always include explicit security requirements in your project specification or agentic plan. This should cover:
+- How secrets are managed, stored, and rotated
+- Who has access to sensitive files and how access is controlled
+- Tools/processes for scanning all files (including documentation) for secrets
+- Regular reviews of code and documentation for accidental secret leakage
+
+[NOTE]
+====
+Always include security instructions on:
+- TLS/SSL usage for all network communications
+- Encryption of sensitive data at rest and in transit
+- Input validation and sanitization to prevent injection attacks
+- Secure authentication and authorization mechanisms
+- Regular dependency and vulnerability scanning
+- Logging and monitoring for suspicious activity
+
+These practices are essential for protecting your application and its data.
+====
diff --git a/src/main/resources/explanations/challenge56.adoc b/src/main/resources/explanations/challenge56.adoc
@@ -6,7 +6,5 @@ The secret is present as an example instruction in the specification file. Your
 
 This challenge demonstrates how secrets can sometimes be hidden in documentation or specification files, which are often overlooked during security reviews.
 
-[NOTE]
-====
+=== NOTE
 This challenge was generated entirely by AI and is therefore very different from the other challenges in this project.
-====
diff --git a/src/main/resources/explanations/challenge56_reason.adoc b/src/main/resources/explanations/challenge56_reason.adoc
@@ -1,3 +1,29 @@
 *Why you should check documentation for secrets*
 
-Documentation and specification files are often shared widely and may be overlooked during security reviews. Sometimes, secrets or sensitive information are added as examples or instructions and are not removed before sharing or publishing. This challenge highlights the importance of reviewing all project files&mdash;including documentation&mdash;for secrets and sensitive data.
+Documentation and specification files are often shared widely and may be overlooked during security reviews.
+Sometimes, secrets or sensitive information are added as examples or instructions and are not removed before sharing or publishing.
+This challenge highlights the importance of reviewing all project files&mdash;including documentation&mdash;for secrets and sensitive data.
+
+----
+
+In a real project, you should always include explicit security requirements in your project specification or agentic plan. This means:
+- Listing how secrets should be managed, stored, and rotated.
+- Defining who has access to sensitive files and how access is controlled.
+- Stating which tools or processes must be used to scan for secrets in all files, including documentation.
+- Requiring regular reviews of both code and documentation for accidental secret leakage.
+
+Adding these requirements helps ensure that security is considered from the start and reduces the risk of sensitive data exposure through overlooked files or bad practices.
+
+[NOTE]
+====
+In real projects, always include security instructions on:
+- TLS/SSL usage for all network communications
+- Encryption of sensitive data at rest and in transit
+- Input validation and sanitization to prevent injection attacks
+- Secure authentication and authorization mechanisms
+- Regular dependency and vulnerability scanning
+- Logging and monitoring for suspicious activity
+- Using the right model and language for the right problem
+
+These practices are essential for protecting your application and its data.
+====
