SaaS Security Audit Without an SSPM Tool: Manual Playbook for Salesforce, GitHub, Okta, and Slack
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
SaaS Security Posture Management tools provide automated, continuous scanning of your SaaS configurations. They are genuinely useful. They are also expensive, require deployment time, and may not be in this year's budget. Meanwhile your Salesforce instance has 200 connected apps, your GitHub organization has public repositories that should be private, your Okta super admin count is growing, and your Slack workspace is sharing files with external guests you have forgotten about.
A manual SaaS security audit using only admin console access and a spreadsheet can find the majority of critical misconfigurations that an SSPM tool would surface. The difference is that a manual audit is a point-in-time snapshot rather than continuous monitoring. Run it quarterly and you close most of the gap.
This playbook covers four platforms that together represent the most common sources of SaaS-related security incidents in mid-to-large enterprises: Salesforce, GitHub, Okta, and Slack. For each platform, specific admin console navigation paths, the exact misconfigurations to look for, and the remediation action are included. Use this as a structured checklist and document your findings in a shared spreadsheet with owner, finding, severity, and remediation date columns.
Salesforce Security Audit
Start with the built-in Security Health Check: Setup > Security > Health Check. This tool gives you a score and flags deviations from Salesforce baseline settings. Review every item marked as medium risk or higher before moving to the manual checks below.
Setup Audit Trail: Setup > Security > View Setup Audit Trail. Export the last 180 days. Filter for the following actions: PermissionSet changes, ConnectedApp changes, AuthProvider changes, and Profile changes. Any changes made outside your change management window or by unexpected users are findings. Salesforce retains audit trail data for 180 days; export it to your SIEM or a secure archive before it ages out.
Permission Sets and Profiles: Setup > Users > Permission Sets. Look for permission sets that include Modify All Data or View All Data granted to users who are not system administrators by role. These permissions provide access to all Salesforce objects regardless of object-level security. Export the permission set assignment list: Setup > Users > Permission Set Assignments. Cross-reference against your HR roster to find terminated employees with active permission sets.
Connected Apps with OAuth: Setup > Apps > Connected Apps > Manage Connected Apps. Review every app in the list. For each app, note whether it has access to the full API, whether user consent can bypass admin approval, and whether the IP restriction policy is set to Enforce. Apps with IP relaxation set to Relax IP Restrictions with second factor and no MFA enforcement are a high-risk configuration. Revoke any app that is not in your approved software catalog or that has not been accessed in the last 90 days.
API-Only Users: Setup > Users > Users, filter by Profile = Salesforce API Only. Every user in this list should be a named service account with a known owner and a documented purpose. API-only users with permissions beyond their documented purpose, or with no documented owner, should be deactivated pending review.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
GitHub Organization Security Audit
Navigate to your organization page, then Settings > Security. Start with the Security Overview dashboard if your organization is on GitHub Enterprise. For non-Enterprise, you will use individual settings pages.
Member Privileges: Settings > Member privileges. Verify that Repository creation is restricted to Private or Internal only, not Public. Verify that Repository forking is disabled for private repositories. Verify that Pages creation is restricted to prevent public publication of internal content. The default member base permissions should be set to Read or None, not Write.
Branch Protection on Default Branch: for each repository that contains production code or sensitive data, navigate to the repository Settings > Branches. Verify that the default branch (typically main) has a branch protection rule requiring: at least one approving review before merging, dismissal of stale reviews when new commits are pushed, required status checks to pass before merging, and restriction of who can push to the branch. The Require linear history option prevents force pushes. Any production repository without these protections on its default branch is a critical finding.
Actions Secrets Scope: Settings > Secrets and variables > Actions. Identify any organization-level secrets. Organization-level secrets are accessible to all repositories in the organization unless you restrict them to selected repositories. A secret with credentials to a production cloud account should never be an organization-level secret; it should be scoped to the specific repository that needs it. Review the Repositories with access column for each secret.
Third-Party OAuth Apps: Settings > Third-party access > GitHub Apps and OAuth Apps. For your organization, navigate to https://github.com/organizations/YOUR-ORG/settings/oauth_application_policy. Review installed apps and the scopes granted. Apps with repo scope can read and write all repositories the authorizing user has access to. Apps with admin:org scope can manage organization settings. Revoke any app not in your approved catalog or with excessive scope for its stated purpose.
Review organization members for dormant accounts: Settings > Members. Sort by recent activity. Members who have not contributed to any repository in 90 or more days should be reviewed; departed employees are commonly missed in SaaS offboarding.
For secret scanning: Settings > Code security and analysis > Secret scanning. Ensure this is enabled for all repositories. If your GitHub tier includes it, enable push protection, which blocks commits containing detected secrets before they reach the repository.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Okta Security Audit
Okta is the authentication backbone for most SaaS environments. A misconfiguration here cascades across every connected application.
Super Admin Accounts: Admin Console > Security > Administrators. Count the number of accounts with the Super Administrator role. Best practice is two to four super admin accounts maximum, all assigned to named individuals, all with hardware MFA enrolled, and all subject to PAM checkout for use. Any super admin account assigned to a shared account, a service account, or a person who has departed the organization is a critical finding. Filter the administrator list by Role = Super Administrator and cross-reference against HR.
Passwordless and MFA Factor Enforcement: Admin Console > Security > Authenticators. Review the authenticator list and which policies require them. Verify that Password + email magic link alone is not permitted as a complete authentication chain for privileged applications. Email-only OTP is not phishing-resistant. Verify that FIDO2/WebAuthn or hardware OTP (Yubikey) is required for admin console access.
API Token Audit: Admin Console > Security > API > Tokens. This page lists all active API tokens. Each token should have a named owner, a known purpose, and a creation date. Tokens older than 90 days without a rotation policy, tokens created by accounts that are now deactivated, and tokens with the description left blank are all findings. Revoke any token that cannot be immediately attributed to an active integration.
ThreatInsight Configuration: Admin Console > Security > General > ThreatInsight. ThreatInsight uses Okta's network-level threat intelligence to identify suspicious sign-in patterns. Verify that ThreatInsight is set to Log and Enforce Block mode, not Log only. Log only provides visibility but does not prevent sign-ins from known malicious IPs. If your environment has edge cases requiring Log only mode, document the business justification.
Suspicious Sign-In Rules: Admin Console > Security > Behavior Detection. Review the behavior detection rules. Verify that New Country, New Device, and Velocity rules are active and configured to step up authentication or block. Review the sign-on policies for your highest-value applications (AWS, GitHub, Salesforce, financial systems) and confirm that behavior anomalies trigger step-up MFA.
Application Integration Audit: Admin Console > Applications > Applications. Filter by Status = Active. Sort by Last Sign-On. Applications with no sign-on in 90 or more days should be reviewed for decommission. Each application should have an owner documented in the Notes field or in your software catalog. Applications without an owner are orphaned integrations that may have over-permissioned attribute mappings.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Slack Security Audit
Slack has become a repository for sensitive data shared informally: screenshots, contracts, personal data, credentials in DMs, and customer information in channel discussions. The security posture of your Slack workspace directly affects your data exposure risk.
Workspace Discovery Settings: Admin Console > Settings > Account and channel settings. Find the Workspace Discovery setting. If your workspace is discoverable to anyone with a company email address, employees from other organizations using the same email domain can join your workspace. This setting should be set to Invitation only for any workspace containing non-public business information.
App Directory Approvals: Admin Console > Apps > App Management. Review whether App Directory Approvals is enabled under Settings. If it is disabled, any user can install any Slack app with full permissions to read channel messages, post on behalf of users, and access files. Enable required admin approval for app installations. Review the list of currently installed apps; any app with bot:write or files:read permissions that is not in your approved catalog should be revoked.
File Sharing to External Workspaces: Admin Console > Settings > Organization settings > External Connections. Review whether file sharing with external Slack Connect channels is enabled and whether any external organizations are connected. Slack Connect allows direct messaging and channel sharing between different Slack workspaces. For each connected external organization, verify that the connection is intentional, documented, and reviewed by the security team.
Slack Audit Log API for Data Exfil Patterns: Slack's Audit Log API (available on Enterprise Grid) provides event logs for file downloads, message exports, user additions to channels, and workspace setting changes. Query the API for these high-signal events:
file_downloaded events with a volume exceeding 100 files per user per day channel_joined events for channels containing sensitive data by users outside the expected department user_logout events from an unusual location following a large file download message_channel events with external guest users in channels tagged as confidential
For non-Enterprise Grid workspaces, use the channel export feature manually: Workspace Settings > Import/Export > Export Messages. Export and review for credentials, API keys, and PII patterns using grep or a pattern matching tool.
Retention Policies: Admin Console > Settings > Message retention and deletion. Verify that message and file retention policies match your data governance requirements. Indefinite retention of all Slack messages creates unnecessary data exposure risk if the workspace is ever compromised. Set retention policies aligned to your data classification: public channels can have longer retention, channels containing client data should have shorter retention with export to a compliant archive.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Building a Quarterly SaaS Audit Process
A one-time audit provides a snapshot. A quarterly process provides drift detection. The goal is to identify when a configuration that was compliant last quarter has changed, not to re-audit from scratch each time.
After your initial audit, document the baseline state for each control in a spreadsheet with the following columns: Platform, Control Name, Current State, Expected State, Status (Pass/Fail/Risk Accepted), Finding Date, Remediation Owner, and Remediation Date.
For each subsequent quarter, re-check only the controls that were either failing or that have a high probability of drift (permission changes, app installations, admin account changes). For each platform, the highest-drift controls are: Salesforce connected apps and permission set assignments, GitHub branch protection and secret scope, Okta API tokens and super admin count, and Slack app installations and external connections.
Automate what you can. Salesforce has a Health Check export. GitHub has an organization audit log API. Okta has a System Log API that can feed a SIEM. Slack has the Audit Log API. Build simple scripts or SIEM saved searches that surface the highest-signal findings for human review rather than requiring a full manual walk-through each quarter.
Assign a named owner for each platform's audit section. The Salesforce admin owns the Salesforce section. The GitHub organization admin owns the GitHub section. Okta audit is owned by the IAM engineer. Slack is typically owned by IT or the collaboration team. Cross-functional ownership ensures institutional knowledge and accountability.
The bottom line
An SSPM tool is a force multiplier for a security team that already knows what to look for. A manual audit using this playbook builds that knowledge base while providing real findings today. Run the Okta super admin check and the GitHub branch protection review as your first two tasks; those two checks find critical misconfigurations in the majority of environments where they have never been run.
Frequently asked questions
How long does a full manual audit of all four platforms take?
For an experienced security engineer, the initial audit of all four platforms takes approximately two to three days. Salesforce requires the most time due to the complexity of permission sets and connected apps. Subsequent quarterly audits take four to eight hours once the baseline is documented and you are checking for drift rather than starting from scratch. Assign one platform per engineer if you have the team to parallelize.
Which platform is most commonly the source of a SaaS-related security incident?
Okta misconfigurations are the highest-leverage target because a compromise propagates to every connected application. Over-permissioned Okta service accounts, weak authentication policies on admin access, and API tokens without rotation are found in most environments that have not done a structured audit. Fix Okta first, then address GitHub because source code access and Actions secrets are frequently exploited in supply chain attacks.
What should I do if I find an OAuth app in Salesforce or Okta that no one can identify?
Treat it as a potential unauthorized access path until proven otherwise. Do not immediately revoke it; first determine whether revoking it would break an undocumented integration. Export the app's last access time, the users who have authorized it, and the scopes granted. Send a communication to the platform owner list asking whether anyone owns this integration. If no owner is identified within five business days, revoke it and monitor for break reports.
Does Slack's Audit Log API require an additional license?
The Audit Log API is available on Slack's Enterprise Grid plan. For Business+ and lower plans, you do not have API access to audit logs. Non-Enterprise Grid workspaces can use the manual message export under Settings > Import/Export, which provides message content but not event-level activity like file downloads or sign-in events. If your risk profile warrants it, this is a legitimate reason to evaluate upgrading your Slack plan.
How do we handle findings where the application owner refuses to remediate?
Document the finding, the recommended remediation, the application owner's decision to accept the risk, and the date of that decision in your audit tracking spreadsheet. Escalate to the application owner's manager if the finding is classified as critical. For findings that remain unresolved after one quarter, escalate to your CISO or risk committee with a written summary. Risk acceptance must be an explicit, documented decision by an authorized owner, not a passive outcome of inaction.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.