Developing Risk-Based Policies

Enterprise SCA policies must reflect actual risk rather than theoretical concerns. Classify applications into risk tiers based on data sensitivity, exposure, and business criticality. Internet-facing applications processing payment data require stricter policies than internal development tools. This tiered approach prevents over-securing low-risk applications while ensuring critical systems receive appropriate scrutiny.

# Example: Risk-Based Policy Framework
risk_tiers:
  critical:
    description: "Customer-facing, payment processing, PII handling"
    vulnerability_policy:
      critical: block_deployment
      high: require_approval
      medium: remediate_within_30_days
      low: track_only
    license_policy:
      forbidden: ["GPL-3.0", "AGPL-3.0"]
      review_required: ["LGPL-3.0", "MPL-2.0"]
    update_requirements:
      max_days_outdated: 90
      
  high:
    description: "Internal apps with sensitive data"
    vulnerability_policy:
      critical: require_approval
      high: remediate_within_7_days
      medium: remediate_within_60_days
      low: track_only
      
  medium:
    description: "Internal tools, non-sensitive apps"
    vulnerability_policy:
      critical: remediate_within_30_days
      high: remediate_within_90_days
      medium: track_only

Implement context-aware policies considering how components are used. A SQL injection vulnerability in a database library might be critical for applications constructing dynamic queries but irrelevant for those using only stored procedures. Reachability analysis determines whether vulnerable code paths are accessible. Environmental factors—network isolation, authentication requirements, compensating controls—influence actual risk. Sophisticated policies prevent alert fatigue while maintaining security.