PolicyIQ

Business Context: Our application processes healthcare data behind a secure API gateway that handles encryption. Internal services communicate over a private network with mutual TLS. All database access is through our custom ORM that implements row-level encryption.

Description: Review code considering our infrastructure. Flag potential PHI exposure but account for our API gateway encryption. Consider our network segregation when evaluating internal service communication. Verify proper use of our custom ORM for database access.

Use Cases:
- Detecting direct database access bypassing our ORM
- Identifying services accidentally exposed outside the API gateway
- Finding improper internal service authentication
- Detecting logging of pre-encryption PHI
- Identifying misuse of our security infrastructure

Business Context: Our test environments use sanitized data and mock services. All external services are replaced with stubs. The test network is isolated and all traffic is monitored. We use a custom test framework that simulates security controls.

Description: Consider our test infrastructure when evaluating security issues. Data that appears sensitive is actually sanitized. External service calls are mocked. Network isolation provides additional security layers.

Use Cases:
- Validating test data handling
- Confirming proper use of service mocks
- Verifying test environment isolation
- Checking sanitized data usage
- Validating test security controls

Business Context: We use a custom security middleware called "SecureMiddleware" that provides XSS protection, among other security features. All web applications must use this middleware for request handling. The middleware automatically sanitizes user input and encodes output to prevent XSS attacks.

Description: Generate fixes that integrate with our SecureMiddleware for XSS protection. Use the built-in sanitization and encoding functions provided by the middleware. Follow our secure coding guidelines for handling user input and rendering output.

Use Cases:
- Implementing XSS protection using SecureMiddleware
Example:
```javascript
// Import the SecureMiddleware
import SecureMiddleware from '../middleware/SecureMiddleware';

// Use the middleware for request handling
router.get('/profile', SecureMiddleware.sanitizeInput(), (req, res) => {
  const username = req.query.username; // Username is now sanitized

  // Render the profile page with encoded output
  res.render('profile', {
    username: SecureMiddleware.encodeOutput(username)
  });
});
`` `
In this example, the `SecureMiddleware.sanitizeInput()` function is used to sanitize the `username` parameter from the query string, preventing XSS attacks through user input. The `SecureMiddleware.encodeOutput()` function is then used to encode the `username` value before rendering it in the template, preventing XSS attacks through output rendering.

- Integrating with our centralized security middleware
Example or description: [Add an content]

- Following secure coding practices for user input handling
Example or description: [Add an content]

- Implementing context-specific XSS protection measures
Example or description: [Add an content]

Business Context: We use a custom security framework that provides encryption, authentication, and audit logging. All services must use our security middleware. We have specific requirements for key rotation and cipher selection.

Description: Generate fixes that integrate with our security framework. Use our standard middleware components. Follow our encryption standards and key management practices. Ensure proper audit logging through our centralized system.

Use Cases:
- Implementing framework-compliant security controls
Example or description: [Add an content]

- Integrating with our authentication services
Example or description: [Add an content]

- Setting up proper audit logging
Example or description: [Add an content]

- Configuring encryption using our standards
Example or description: [Add an content]

- Establishing service-to-service authentication
Example or description: [Add an content]

- Implementing environment-specific security measures
Example or description: [Add an content]

# This is the corgea YAML file used for defining and managing security policies within applications.
# For more information, visit: https://docs.corgea.app/policies
version: 1  # Specifies the version of the corgea YAML standard being used. Update only if the standard changes.
policies:
  - type: "scan"
    description: >
      This section ensures that all directories and files are thoroughly scanned to detect any security vulnerabilities in the backend code.
      It is essential to identify and address potential issues such as SQL injection, exposure of sensitive data, and unauthorized access.
      Comprehensive scanning helps maintain the security and integrity of the application.

policies:
  - type: "fix"
    instruction_type: "append"
    guidance_text: >
      Use our secure logging utility and do not log raw request payloads.
    description: >
      Additionally, ensure all fixes integrate with our custom SecureMiddleware framework
      and follow our internal security guidelines for key rotation.
    cwes:
      - "CWE-79"  # XSS

cwes:
      - "CWE-20"  # CWE-20: Improper Input Validation
      - "CWE-78"  # CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
      - "CWE-209" # CWE-209: Information Exposure Through an Error Message
      - "CWE-362"
      - "CWE-79"

   excludes:
      - "config/*"
      - "migrations/*"

   ignore_paths:
      - "test/*"

# This is the corgea YAML file used for defining and managing security policies within applications.
# For more information, visit: https://docs.corgea.app/policies
version: 1  # Specifies the version of the corgea YAML standard being used. Update only if the standard changes.
policies:
  - type: "scan"
    path: 'backend'
    description: >
      ...
  - type: "scan"
    path: 'frontend'
    description: >
      ...
  - type: "fix"
    path: 'backend'
    description: >
      ...
    cwes:
      - "CWE-22"  # CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
  - type: "false_positive"
    path: 'backend'
    description: >
       ....
    cwes:
      - "CWE-20"  # CWE-20: Improper Input Validation
  - type: "false_positive"
    path: "frontend"
    description: >
      ...
    cwes:
      - "CWE-79"  # CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')