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.

This edition preserves the policies from January 23, 2026. For current setup instructions, see Custom Code Policies. Choose a policy below, then adapt its question and background to your application.

GitHub Action Policy

Question

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.

Background

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

Question

Does this code introduce a new API endpoint without authorization enforcement?

Background

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

Question

Does any file in the codebase include references (e.g., via <script> tags, import/require statements, or dynamic loading functions) to third-party scripts?

Background

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

Question

Does any logging function in the codebase output sensitive data (such as passwords, API keys, or secret tokens)?

Background

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

Question

Does this change introduce username enumeration flaws?

Background

Username enumeration flaws typically happen when system error messages indicate the presence of a user account.

Token Validation Check

Question

Are there any logical flaws in our token validation or generation logic?

Background

Tokens need to be generated using a secure algorithm that has high entropy, and they must be validated securely.

Insecure File Upload Handling

Question

Does this change introduce or modify file upload functionality in a way that might allow dangerous files to be uploaded and executed?

Background

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

Question

Does this change expose detailed internal error messages or stack traces to end users that might reveal sensitive implementation details?

Background

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

Question

Does this change modify Cross-Origin Resource Sharing (CORS) settings in a way that might allow unauthorized websites or origins to access sensitive endpoints?

Background

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

Question

Does this change affect how microservices communicate, potentially bypassing secure channels, authentication, or authorization measures?

Background

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

Question

Does this change deserialize data from untrusted sources without proper validation or secure safeguards?

Background

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

Question

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)?

Background

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.

Hard-Coded Credentials Detection

Question

Does this change introduce hard-coded credentials such as passwords, API keys, tokens, or secret access keys?

Background

Hard-coding credentials directly into source code poses a serious security risk. These secrets can be inadvertently leaked, stored in version control, or exposed during logging or error handling. This policy should return true if the code includes any strings or variables that suggest credentials are embedded, such as:

  • Assignments to variables like password, secret, token, apikey, auth, or access_key
  • Sensitive keys or secrets committed into .env, .yaml, .json, or configuration files

When detected, include the file path, and line number where the issue appears. Do not repeat the credentials in the results.