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: [if applicable]
      recommendation: [brief]
  sandbox_governance_findings:
    - sandbox_name: [sanitized name or type label]
      sandbox_type: Developer | Developer Pro | Partial | Full
      masking_configured: true | false | unknown
      finding: [description]
      severity: Critical | High | Medium | Low
      recommendation: [brief]
  change_impact_findings:
    - metadata_type: [e.g., CustomField, ApexClass, Flow]
      component: [sanitized name]
      finding: [description]
      severity: Critical | High | Medium | Low
      downstream_automation_impact: [list or "none identified"]
      recommendation: [brief]
  cicd_gate_findings:
    - gate: [gate name]
      status: present | absent | advisory-only
      severity: Critical | High | Medium | Low
      recommendation: [brief]

sca_summary:
  p1_critical: [count]
  p2_high: [count]
  p3_medium: [count]
  p4_advisory: [count]
  false_positive_claims: [count]

cicd_gate_matrix:
  sca_fail_threshold: present | absent | advisory-only
  test_coverage_gate: present | absent | below-minimum
  cve_scan: present | absent | advisory-only
  destructive_change_approval: present | absent
  sandbox_verification: present | absent

escalation_gates_fired: [from salesforce-risk-taxonomy, or "none"]
summary:
  total_findings: [count]
  critical_count: [count]
  high_count: [count]
  deployment_recommendation: block | conditional | proceed
assumptions: [list]
missing_evidence: [what would improve the review]

Redaction rules

• Never request secrets, credentials, OAuth tokens, refresh tokens, session IDs, MFA seeds, customer PII.
• Sanitize org IDs, user IDs, sandbox names before sharing in outputs.
• SCA output must not include hardcoded credentials or API keys found in code — stop and request sanitized version.

Privilege / data handling rules

• Works from SCA tool output, sanitized pipeline configs, and metadata manifests only.
• Sandbox findings involving unmasked production data must be flagged for compliance specialist review.
• P1 SCA findings in Apex classes handling PII or financial data must trigger escalation review.
• Destructive change findings must be escalated to a change advisory board or equivalent human review.

Handoff rules

• Hands off to: salesforce-apex-lwc-code-review-skill (if P1 SCA findings require deeper code-level review), salesforce-release-readiness-skill (after pipeline findings are remediated and deployment approval is needed), salesforce-permission-model-review-skill (if permission set or profile changes are in the deployment), salesforce-case-capsule (for any P1 Critical finding or missing required CI/CD gate).
• Required handoff fields: matter_id, risk_register (summary), escalation_gates_fired, missing_evidence, assumptions.

Audit log fields

• matter_id, skill_id, skill_version, invoked_by, input_hash, evidence_quality, output_verdict, escalation_fired, timestamp

Stop conditions

• SCA output or pipeline config contains live credentials, session tokens, or unredacted customer PII — stop and request sanitized version.
• P1 Critical SCA finding confirmed on a production-bound deployment with no remediation plan — stop, output ESCALATE, require human review before continuing.
• Destructive change manifest confirmed for a production deployment without a documented rollback plan — stop and require change advisory board review.
• Full sandbox confirmed to contain unmasked production PII feeding a pipeline with no masking gate — stop and require compliance specialist review.

Security notes

• Read-only static review; never requests live org access, executes deployments, or triggers pipeline runs.
• Sanitized inputs only; SCA outputs containing hardcoded credentials must be refused.
• Risk register is advisory; P1 blocking decisions and destructive change approvals require human authorization.
• RetireJS CVE findings reference public CVE records; applicability to the specific Salesforce runtime context requires qualified assessor confirmation.