Generic Starter Pack NLCPs
"Starter Pack" NLCPs
The following Natural Language Code Policies can be used to help you get started. They are generic to be customized by your organization but can be used "as-is", as well.
| Name | Question | Background |
|---|---|---|
| GitHub Action Policy | Carefully examine any GitHub Actions related changes or inline commands for security risks. Provide results in the form of a list with line numbers and with the following title: Identified GitHub Actions Risks. | We are concerned about the following: • Use of untrusted or mutable third-party actions (e.g., actions without a specific commit hash or version tag) • Secrets exposure (e.g., secrets passed to untrusted actions or exposed via echo) • Unsafe use of run: commands (e.g., using unsanitized inputs or shell injection)• Privilege escalation (e.g., setting permissions: write-all or using a job with GITHUB_TOKEN that can trigger another workflow)• Insecure usage of pull_request_target trigger (especially with run: or secrets)• Workflow that can be triggered by forks with write access to secrets or the repo |
| New API Endpoint w/o authz | Does this code introduce a new API endpoint without authorization enforcement? | We are concerned about new API routes or endpoints being added to our application that lack any type of enforcement. To determine if the endpoint has authorization applied, change as needed: either use the default framework annotations (e.g., before_filter current_user) or check the file /access_defintions.go to determine if the endpoint has been added without authz. |
| Third Party Scripts | Does any file in the codebase include references (e.g., via <script> tags, import/require statements, or dynamic loading functions) to third-party scripts? | Introducing third-party scripts into our application's presentation view (e.g., HTML/JavaScript) means that our attack surface is expanded and someone else's code can interact with our user's browser. We need to avoid introducing these types of scripts into our application code base. |
| Logging Sensitive Data | Does any logging function in the codebase output sensitive data (such as passwords, API keys, or secret tokens)? | Logging sensitive data can inadvertently expose secrets if logs are accessed by unauthorized parties. This question returns true if there is any instance where a logging function outputs data that is considered sensitive, and false if all logging calls have been verified to avoid such data. |
| Username Enumeration | Does this change introduce username enumeration flaws? | Username enumeration flaws typically happen when system error messages indicate the presence of a user account. |
| Token Validation Check | Are there any logical flaws in our token validation or generation logic? | Tokens need to be generated using a secure algorithm that has high entropy, and they must be validated securely. |
| Insecure File Upload Handling | Does this change introduce or modify file upload functionality in a way that might allow dangerous files to be uploaded and executed? | File uploads, if not strictly validated, pose a risk of allowing attackers to send files that could execute malicious code or serve as an entry point for further attacks. This could compromise server security or lead to data breaches. |
| Improper Error Handling | Does this change expose detailed internal error messages or stack traces to end users that might reveal sensitive implementation details? | Detailed error messages or stack traces can provide attackers with insights into the application’s internal logic, potentially revealing vulnerabilities or configuration details. While internal logging is crucial for debugging, user-facing messages should be concise and non-revealing. |
| Insufficient CORS Configuration Check | Does this change modify Cross-Origin Resource Sharing (CORS) settings in a way that might allow unauthorized websites or origins to access sensitive endpoints? | Overly permissive CORS settings can open the door to cross-origin attacks or unintended data leakage, particularly if sensitive APIs are exposed. A misconfiguration might let unauthorized domains interact with your application, potentially leading to data exfiltration or misuse of the API. |
| Inadequate Security of Inter-Service Communication Check | Does this change affect how microservices communicate, potentially bypassing secure channels, authentication, or authorization measures? | In a microservices architecture, inter-service communication often transmits sensitive data. If these channels are not properly secured (e.g., lacking mutual TLS or relying solely on IP-based trust), they may expose sensitive endpoints to interception or tampering, leading to lateral movement or broader system compromise. |
| Insecure Deserialization Handling Check | Does this change deserialize data from untrusted sources without proper validation or secure safeguards? | Unvalidated deserialization of data can lead to severe vulnerabilities, including remote code execution or denial of service. Deserialization flaws are particularly dangerous when user input or externally sourced data is directly converted back into objects without integrity checks. |
| PHI/PII Exposure | Does this change result in the exposure of sensitive PII or PHI through code, logs, network transmissions, or repository artifacts (e.g., inline comments, debug statements, or poorly protected files)? | Exposing PII/PHI can lead to severe privacy breaches, legal ramifications, and reputational damage. Sensitive data, especially health-related information (PHI), must be handled following legal regulations such as HIPAA, GDPR, or other applicable standards. The inadvertent disclosure might occur if sensitive information is logged, embedded in error messages, or transmitted insecurely. It is critical that any access to or display of such data is strictly controlled and monitored. |