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.