SOC 2 mapping
SOC 2 is the audit most enterprise-tier SaaS vendors and managed-service providers carry. For a Salesforce-deployed app, the SOC 2 audit asks whether the technical controls protecting the org meet the Trust Services Criteria. This page maps the criteria most relevant to a Salesforce deployment onto the Vulkro detectors that produce evidence for them.
For the non-Salesforce half of a SOC 2 audit (web app, API, mobile, cloud infrastructure), see the general-scanner SOC 2 page.
Run it
vulkro-sf scan ./force-app --compliance soc2
vulkro-sf scan ./force-app --compliance-pack soc2 -o soc2-readiness.html
The HTML report is grouped by Trust Service Criterion and prints a PASS / FAIL / NOT EVALUATED verdict per control row.
Trust Services Criteria covered
| Criterion | Title | Vulkro detector(s) that feed it |
|---|---|---|
| CC6.1 | Logical access provisioning | profiles-permsets (over-privilege, dormant admins), security-settings (password policy, MFA via session settings) |
| CC6.2 | User access removal | profiles-permsets (dormant admin detection) |
| CC6.3 | Least privilege | profiles-permsets (over-privilege detection: ModifyAllData, AuthorApex, CustomizeApplication) |
| CC6.6 | External-system access | connected-apps (OAuth posture, Drift / Gainsight class), named-credentials |
| CC6.7 | Sensitive data transmission | security-settings (requireHttps enforcement), connected-apps (OAuth scope review) |
| CC6.8 | Malicious code prevention | detectors/apex (crypto misuse, hardcoded secrets), org-packages (beta package warning) |
| CC7.1 | Vulnerability detection | The whole scan. This is what vulkro-sf does. |
| CC8.1 | Change management | CI/CD integrations (PR-gate evidence, baseline snapshots) |
| CC9.1 | Risk mitigation | security-settings (hardening posture), connected-apps (third-party data flow risk) |
| C1.1 | Confidential information at rest | pii-map (sensitive SObject inventory) |
Per-criterion detail
CC6.1 Logical access provisioning
The Trust Service Criterion: the entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.
In a Salesforce org, that means three things: profiles and permission sets do not over-grant, MFA is enforced, and password policy is set to something more than the platform minimum.
Vulkro emits findings for:
- Profile or permission set carrying any of
ModifyAllData,AuthorApex, orCustomizeApplicationoutside the System Administrator profile. - Session settings with MFA absent or weak.
- Password policy below the documented baseline (length, complexity, history, expiration).
CC6.2 User access removal
The criterion: prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users; access is removed when no longer required.
Vulkro flags dormant admin profiles: profiles with admin-equivalent permission grants that have not been assigned to an active user in a period exceeding the documented threshold. The full org-side audit needs a live org pull (the org-status connector) to see actual user assignments.
CC6.3 Least privilege
The criterion: the entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties.
Vulkro's profile / permission set detector emits over-privilege findings any time a non-admin profile carries an admin-equivalent grant.
CC6.6 External-system access
The criterion: the entity implements logical access security measures to protect against threats from sources outside its system boundaries.
For a Salesforce org, the system-boundary surface is Connected Apps, Named Credentials, and (increasingly) Agentforce / Einstein 1 integrations. Vulkro covers:
- Connected App OAuth scope review (the "Full access" scope is flagged).
- Connected Apps in the Drift / Gainsight breach class (third-party OAuth integrations with the same posture as the 2024-25 ShinyHunters incidents).
- Named Credentials with cleartext (
http://) endpoints. - Named Credential secrets in metadata (credential leaks committed to source).
CC6.7 Sensitive data transmission
The criterion: the entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal.
Vulkro checks:
SecuritySettings.requireHttpsenforcement on every login route and Site / Experience Cloud surface.- Connected App callback URLs on
https://. - Outbound callouts to non-TLS endpoints.
CC6.8 Malicious code prevention
The criterion: the entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software.
Vulkro emits findings for:
- Crypto misuse in Apex (deprecated algorithms, weak modes, insecure-random sources).
- Hardcoded credentials in Apex source.
- Org-status warnings for installed beta managed packages (a beta package is functionally unreviewed code running in the org with whatever access the installer granted).
CC7.1 Vulnerability detection
The criterion: to meet its objectives, the entity uses detection and monitoring procedures to identify changes in configurations that result in the introduction of new vulnerabilities, and susceptibilities to newly discovered vulnerabilities.
This is what vulkro-sf does. The whole scan is the evidence for this
control. The SARIF output is the artifact.
CC8.1 Change management
The criterion: the entity authorizes, designs, develops, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.
The CI/CD integration is the evidence here. A PR-gate that runs
vulkro-sf on every change and fails the build on new findings is the
auditor-facing artifact for change management. See CI/CD
integration for the GitHub Actions wiring and the
baseline-snapshot pattern.
C1.1 Confidential information at rest
The criterion: the entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality.
The Salesforce-shaped version of this control is "where does PHI / PCI
/ PII actually live in the org?" Vulkro's PII map detector emits a
sensitive-SObject inventory with field-level annotations, by default
covering the standard PII fields (Email, Phone, Address__c,
SSN__c) and surfacing custom-field naming patterns that suggest
sensitivity.
Audit evidence: what to hand the auditor
The artifacts an auditor wants:
- The SARIF file from each scan. Every finding has a finding ID, severity, file / line, framework tags, and the scan's UTC timestamp. SARIF is the OASIS standard format auditors accept directly.
- The compliance-pack HTML report.
vulkro-sf scan --compliance-pack soc2 -o soc2-readiness.htmlproduces a single self-contained HTML file. Save as PDF for the audit package. - The baseline file.
vulkro-sf scan --baseline baseline.jsonis the dated snapshot. Each new scan diffs against it. The baseline is the "as of date X" evidence row in the SOC 2 system description. - The CI workflow log. GitHub Actions / GitLab CI runs of
vulkro-sfare the change-management evidence (CC8.1).
What's NOT covered
A scanner does not produce evidence for the organizational TSCs. SOC 2 also asks the auditor to evaluate:
- CC1 Control Environment: the entity demonstrates a commitment to integrity and ethical values, board independence, organizational structure, and accountability.
- CC2 Communication and Information: the entity obtains or generates and uses relevant, quality information to support the functioning of internal control.
- CC3 Risk Assessment: the entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.
- CC4 Monitoring Activities: the entity selects, develops, and performs ongoing or separate evaluations.
- CC5 Control Activities: the entity selects and develops control activities and general controls over technology.
These need written policy, signed contracts, evidence of training, and documented governance. Vulkro does not produce them. A SOC 2 Type II audit needs both the technical evidence Vulkro emits and the organizational evidence your operations team builds.
Per-detector control map (AP-001 through AP-055)
The mapping below pairs each Well-Architected anti-pattern detector with the SOC 2 Common Criteria it contributes evidence for. Auditors care about four CC controls for a Salesforce surface: CC6.1 (logical access), CC6.6 (authentication / credentials), CC7.2 (detection and monitoring), and CC8.1 (change management).
CC6.1 - Logical and physical access controls
| Detector | What the finding shows |
|---|---|
| AP-015 PII in debug log | Customer data flowed into Setup audit, broader read population than data classification permits |
| AP-016 Record serialized into log | Same as AP-015, at field-set granularity |
| AP-017 PII in audit/log custom field | Customer data duplicated into non-encrypted store |
| AP-018 Agentforce action with no input validation | AI agent can issue arbitrary queries against unrestricted scope |
| AP-019 Agent with broad PII access | Agent reachable from chat owns Read/Edit/All on a PII object |
| AP-026 Trigger silent-swallow | Trigger-context error did not trigger detection / response |
| AP-029 Cross-package class no Type.forName | Optional dependency not guarded, runtime exposure |
| AP-032 Lookup where master-detail required | Sharing rule on parent did not protect child |
| AP-034 Profile count above threshold | Permission audit harder to perform at scale |
| AP-035 Permission-set sprawl | Effective permission of any user is opaque |
| AP-036 Connected App sprawl | Third-party reachable surface above review threshold |
| AP-037 Agentforce action sprawl | AI surface above security-review threshold |
| AP-040 God method | Service code mixes query + DML + logic, harder to audit access decisions |
| AP-041 @AuraEnabled with inline SOQL | Controller bypasses selector layer; access path not abstracted |
| AP-044 REST endpoint without auth check | Endpoint reachable without identity verification |
| AP-046 Flow runs in System mode against PII | Sharing rules bypassed; auditor cannot confirm enforcement |
| AP-047 List Custom Setting holds secret | Credentials readable by all authenticated users |
| AP-048 Public Custom Metadata holds secret | Credentials readable through standard SOQL |
CC6.6 - Authentication and credential management
| Detector | What the finding shows |
|---|---|
| AP-012 Hardcoded callout URL (no Named Credential) | Outbound credential not routed through documented rotation point |
| AP-022 Agent grounding via Drift-class Connected App | Authentication route inherits a known-vulnerable OAuth surface |
| AP-024 Partial-success DML without SaveResult | Auth-driven failures dropped silently |
| AP-025 Callout failure swallowed by empty catch | Auth failures not surfaced to detection |
| AP-027 Installed package on Beta | Auth path against a package with no upgrade guarantee |
| AP-042 Callout without retry path | Auth-related transient failures become hard transaction failures |
| AP-043 Callout without setTimeout | Long-running auth requests block the transaction budget |
| AP-045 External Service Registration with NoAuthentication | Integration bypasses credential check entirely |
| AP-052 Browser localStorage / sessionStorage access | Session-scoped credentials cross user boundaries on shared devices |
CC7.2 - Detection and monitoring of system events
| Detector | What the finding shows |
|---|---|
| AP-001 SOQL in loop | Governor-limit risk that surfaces only under load |
| AP-002 DML in loop | Governor-limit risk under load |
| AP-004 Empty catch | Operationally significant failures not surfaced |
| AP-008 Schema describe in loop | Performance failure mode not monitored |
| AP-013 SOQL without WHERE/LIMIT | Resource-exhaustion failure mode not bounded |
| AP-023 Catch-and-rethrow without context | Stack frames lost; incident response harder |
| AP-030 Formula >3 levels deep | Deploy-time failure mode not surfaced until production |
| AP-031 Junction object with two lookups | Cascade-delete semantics not enforced |
| AP-033 Flow Get Records in loop | Governor-limit failure not detected at design time |
| AP-038 Custom Apex reimplementing Validation Rule | Validation failure not visible to standard admin audit |
| AP-049 PII write without paired delete | Right-to-erasure event has no execution path |
| AP-050 LWC / Aura direct DOM write | XSS event not detected by framework auto-escape |
| AP-051 LWC / Aura eval / new Function | Script-injection event not detected by review |
| AP-053 Visualforce actionPoller below 60s | Resource-exhaustion failure mode under load |
| AP-054 Visualforce escape=false on outputText | XSS event reachable through merge fields |
| AP-055 Visualforce third-party off-platform script | Supply-chain event surface outside CSP boundary |
CC8.1 - Change management
| Detector | What the finding shows |
|---|---|
| AP-003 Hardcoded record ID | Change to record IDs requires source edit + deploy |
| AP-005 Trigger logic in body | Change required without handler-class indirection |
| AP-006 @future in trigger | Async pattern decision baked into the trigger surface |
| AP-007 Apex class with no test | Change cannot demonstrate 75% AppExchange coverage gate |
| AP-009 Multiple triggers per object | Order-of-execution change requires coordination doc |
| AP-010 Recursive trigger DML | Recursion-guard change requires source edit |
| AP-011 Mixed-DML transaction | Setup/non-setup boundary change requires transaction rewrite |
| AP-014 @isTest(SeeAllData=true) | Test does not survive AppExchange submission |
| AP-028 Hardcoded namespace prefix | Repackage / re-namespace change requires source edit |
| AP-039 Flow reimplementing Approval Process | Change-management view does not see this approval in standard report |