salesforce-devsecops-pipeline-skill

Salesforce DevSecOps Pipeline Skill

Purpose

This skill conducts a structured DevSecOps review of Salesforce development pipelines — including Salesforce Code Analyzer (SCA) finding triage, sandbox data governance and PII masking adequacy, change impact assessment across metadata dependencies and downstream automation, CI/CD security gate compliance, and DevOps Center deployment governance. It produces a prioritized remediation register without accessing live orgs or executing deployments. It is the shared workflow called by DevSecOps and pipeline governance agents in the Salesforce agent catalog.

When to use

• SCA or PMD/ESLint/RetireJS findings from a pipeline run require structured triage and severity classification.
• Sandbox refresh governance and PII masking adequacy must be assessed before data is loaded.
• A change impact analysis is needed to identify metadata dependencies, downstream automation risk, and destructive change exposure.
• CI/CD pipeline security gate configuration must be reviewed against a minimum control baseline.
• DevOps Center deployment governance — work item traceability, approval gates, promotion rules — needs audit.

When not to use

• Apex or LWC code pattern review (logic-level code review) — use salesforce-apex-lwc-code-review-skill.
• Release readiness approval gate with sign-off workflow — use salesforce-release-readiness-skill.
• Live deployment execution or change approval — use salesforce-live-change-approval-protocol.
• Permission model or sharing rule changes — use salesforce-permission-model-review-skill.
• Full org posture assessment combining all domains — use salesforce-org-assessment-skill.

Minimum payload (required inputs)

• SCA output: PMD rule violations, ESLint issues, RetireJS CVEs, tool version, scan scope (full org vs. delta).
• Sandbox inventory relevant to the pipeline: sandbox type, data masking configuration, last refresh date.
• Change inventory: metadata types being deployed, destructive change manifest (if any), field type changes.
• CI/CD pipeline configuration summary: gate names, pass/fail criteria, tool integrations.
• Context: deployment target environment (sandbox, staging, production), release timeline, regulatory framework.

Workflow

1. SCA findings triage

• Review all PMD rule violations from the SCA output.
• Classify findings by severity tier:
• P1 Critical: security vulnerabilities (SOQL injection, XSS, credential exposure, without sharing on PII classes).
• P2 High: governor-limit risks, missing FLS enforcement, unsafe async patterns.
• P3 Medium: code quality issues, missing documentation, test coverage gaps.
• P4 Advisory: style suggestions, minor refactor recommendations.
• Flag: any P1 Critical finding — these must block deployment until resolved.
• Review ESLint issues for LWC components: flag any security-relevant rules (no-eval, no-inner-html, no-unsanitized).
• Review RetireJS CVE list: flag CVEs with CVSS score ≥ 7.0 as P1; flag CVSS 4.0–6.9 as P2.
• Record total finding count by severity tier and tool source (PMD / ESLint / RetireJS).

2. False positive review

• For each finding flagged for false positive consideration, require:
• The rule ID and description.
• The specific code pattern triggering the finding.
• A documented rationale for why the pattern is not a risk in this context.
• Flag: false positive claims on security-critical rules (SOQL injection, XSS, credential exposure) — these require security specialist sign-off, not self-service suppression.
• Flag: blanket suppression annotations (@SuppressWarnings('all') or equivalent) without scoped justification.
• Record false positive claims with rule IDs and rationale for audit trail.

3. Sandbox governance check

• Review sandbox type against the intended test data classification:
• Developer or Developer Pro sandbox: must not receive masked-production data without explicit governance approval.
• Partial sandbox: confirm masking rules cover all regulated field types before refresh.
• Full sandbox: confirm masking configuration is applied before every refresh from production.
• Flag: Full or Partial sandbox refreshed from production without a data masking configuration present.
• Flag: sandbox with external vendor or contractor access that lacks network access restrictions.
• Flag: sandbox refresh policy absent or refresh interval undocumented for sandboxes used in the pipeline.
• Flag: pipeline configured to deploy directly to Full sandbox without a preceding security gate pass.
• Record sandbox type, masking status, last refresh date, and external-access flag.

4. Change impact assessment

• Review the metadata deployment inventory for dependency risk:
• Flag: custom field type changes (e.g., Text → Picklist, Number → Text) — data conversion risk.
• Flag: destructive changes in the deployment manifest (field deletions, object deletions, class removals) — confirm rollback plan exists.
• Flag: Apex class changes that affect trigger handlers, batch jobs, or scheduled classes without test coverage update.
• Flag: Flow or Process Builder metadata changes that affect production-active automations without deactivation plan.
• Flag: permission set or profile changes included in the deployment — require permission model review handoff.
• Map downstream automation impact: identify Flows, Process Builders, triggers, or scheduled jobs that reference changed metadata.
• Flag: changed metadata referenced by active production automations with no stated deactivation or coordination plan.
• Flag: API version downgrade in any Apex class or LWC component included in the deployment.
• Record total metadata component count, destructive change count, and downstream automation impact count.

5. CI/CD security gate compliance

• Review the pipeline configuration for the following required security gates:
• SCA scan with fail threshold on P1 findings (required).
• Test execution with minimum 75% code coverage gate (required; 85% recommended for regulated orgs).
• Static analysis for dependency CVEs (RetireJS or equivalent) (required).
• Destructive change review gate — manual approval required before any destructive change deployment (required).
• Sandbox deployment verification before production promotion (required).
• Flag: any required gate absent from the pipeline configuration.
• Flag: SCA gate configured as advisory-only (no fail threshold) — this does not constitute a security gate.
• Flag: test coverage gate absent or set below 75%.
• Flag: production promotion path that bypasses sandbox deployment verification.
• Record gate presence matrix: gate name → present | absent | advisory-only.

6. Risk register assembly

• Consolidate findings from steps 1–5.
• Assign risk_tier per finding: Critical | High | Medium | Low.
• Map each finding to its pipeline domain: sca | false_positive | sandbox | change_impact | cicd_gate.
• Assign remediation priority: P1 must block deployment; P2 should resolve before promotion; P3 resolve within sprint; P4 advisory.
• Identify findings that meet escalation gates from salesforce-risk-taxonomy.

Evidence requirements

• SCA output with rule IDs and finding counts is required for step 1; absence produces "insufficient evidence — assume all gates unverified".
• Sandbox inventory with masking configuration is required for step 3.
• Metadata deployment manifest is required for step 4; absence produces "change impact assessment not possible".
• CI/CD pipeline configuration or gate summary is required for step 5.
• Absence of any required input produces an "insufficient evidence" note with conservative (worst-case) rating for that domain.

Output format

devsecops_pipeline_findings:
  sca_findings:
    - tool: PMD | ESLint | RetireJS
      rule_id: [rule identifier]
      severity_tier: P1 | P2 | P3 | P4
      description: [brief]
      false_positive_claim: true | false
      false_positive_rationale: