[thegeneraldeborah-dev]

Overview

This PR adds policy-as-code evaluation to the analyzer and scanner pipeline so builds can be failed based on configurable policies that match on severity, rule ID, file path, or finding count.

Related Issue

Changes

🛡️ Policy Evaluation

• [MODIFY] apps/api-service/src/analyzer/interfaces/analyzer.interface.ts

  • Adds policy and evaluation result types used by the analyzer output.

• [MODIFY] apps/api-service/src/analyzer/dto/analyze-request.dto.ts

  • Accepts an optional policy configuration on analysis requests.

• [MODIFY] apps/api-service/src/analyzer/analyzer.service.ts

  • Evaluates configured policies against findings and marks the result as pass/fail.

📏 Rules and Scanner Integration

• [MODIFY] apps/api-service/src/rules/interfaces/rules.interface.ts

• [MODIFY] apps/api-service/src/rules/rules.service.ts

• [MODIFY] apps/api-service/src/rules/rules.controller.ts

  • Exposes rule metadata needed to validate policy rule references.

• [MODIFY] apps/api-service/src/scanner/dto/scan-request.dto.ts

• [MODIFY] apps/api-service/src/scanner/scanner.service.ts

  • Passes policy configuration through the scan flow and applies the resulting pass/fail decision.

Verification Results

No new test files are included in this change set, so no test results are claimed here. Reviewers should run the existing API service test suite and CI before merge.

Acceptance Criteria	Status
Policies can fail builds by severity, rule, path, or finding count	✅ Implemented in analyzer and scanner evaluation paths
Automated tests cover primary and failure paths	⚠️ Not yet added — follow-up required
Security and operational implications documented	⚠️ Pending — see notes below
CI passes with no new critical or high-severity findings	⏳ To be confirmed by CI
Documentation or runbook updates	⚠️ Not included in this PR

Security and Operational Notes

• Policy configuration is user-supplied; it should be validated server-side (DTO validation) to avoid malformed or overly permissive rules silently disabling failures.
• Failing builds on finding count thresholds can block pipelines; teams should roll out policies in a non-blocking mode first.
• No credentials, keys, or production data are added in this change.

Follow-ups

• Add unit tests for pass/fail evaluation across severity, rule, path, and count policies.
• Document policy schema and examples in the API docs/runbook.

Closes #977