Security Scanning

The One Code's Govern module includes two security scanning capabilities: Secret Scanning, which finds leaked credentials in repository file contents and git history, and Access Audits, which audit organization membership, team permissions, and 2FA compliance.

Secret Scanning

Secret scanning reads the contents of your clients' repositories looking for accidentally committed credentials. Finding these before a bad actor does is one of the highest-value services an MSP can offer.

What It Detects

The scanner identifies the following credential types:

Secret Type	Examples
api_key	Generic API keys, service keys, integration tokens
password	Hardcoded passwords in config files or code
token	OAuth tokens, personal access tokens, bearer tokens
private_key	RSA/EC private keys, PEM-encoded keys
connection_string	Database connection strings with embedded credentials
aws_key	AWS Access Key IDs and Secret Access Keys
azure_key	Azure storage account keys, Cosmos DB keys, SAS tokens
jwt_secret	JWT signing secrets
other	Other high-entropy strings matching known credential patterns

For each detected secret, the scanner records:

• File path — exactly where in the repo it was found
• Line number — precise location
• Severity — critical, high, or medium
• Snippet — a redacted preview showing only the first and last 4 characters (e.g., AKIA...XYZW)
• Committed by — the GitHub user who introduced the secret
• Committed at — when it was introduced
• Active — whether the secret is still present in the HEAD of the default branch (vs. only in git history)

Running a Secret Scan

Scan a single repository:

1. Navigate to the repository detail page
2. Click Scan for Secrets
3. The scan runs immediately and results appear within a minute or two

Scan all repos in an org:

1. Navigate to the organization detail page
2. Click Scan All Repos
3. Scans are queued for all repositories in the org

Scheduled scanning:

A background timer runs secret scans across all connected organizations on a regular schedule. You don't need to trigger scans manually to stay current.

The Secrets Dashboard

Navigate to Secret Scan from the left sidebar to see the security dashboard:

• Total secrets detected — across all repos in the tenant
• Active secrets — secrets still present in the HEAD of the default branch (high priority to remediate)
• Remediated secrets — secrets you've marked as resolved
• By repository — breakdown of which repos have the most findings
• By severity — how many critical vs. high vs. medium findings

⚠️An "active" secret means the credential is still in the current codebase. Even if it was rotated, it exists in git history and may be extractable by anyone with repo access. "Active" findings need immediate attention.

Marking Secrets as Remediated

After you've addressed a finding — rotated the credential, removed it from git history (force push or BFG Repo-Cleaner), and confirmed it no longer grants access — mark it as remediated:

1. Find the secret finding in the dashboard
2. Click Mark Remediated
3. The finding moves to the "Remediated" section and remediated_at is recorded

The next scheduled scan will re-scan the repo. If the secret is no longer found, it won't reappear. If the scan finds the same secret pattern again, a new finding is created.

Comparing to Previous Scans

When a new scan runs, The One Code compares it to the previous scan for that repository. If new secrets appeared since the last scan, a code.security.new_secret_detected event is published to The One Bus. If you have PSA integration configured, this event can trigger an automatic PSA ticket.

---

Access Audits

Access audits give you a complete picture of who can access your clients' GitHub organizations and whether their permission levels are appropriate.

What Access Audits Capture

An access audit collects:

Organization Members

• GitHub login and ID
• Role (admin or member)
• Whether 2FA is enabled
• Number of repositories accessible
• Last active date (if available)
• Email address (if available)

External Collaborators

• GitHub users who have repo-level access but are not org members
• Which repos they can access and their permission level
• When they were added and by whom

Teams

• Team names and slugs
• Member counts
• Which repos the team has access to and at what permission level
• Individual team member list

2FA Compliance

• Whether the organization requires 2FA
• Count of members with 2FA enabled vs. disabled
• List of non-compliant members

Permission Drift

• Repos where users or teams have more access than expected
• Orphaned access (users with access to repos who are no longer org members)
• Admin sprawl (too many users with admin permission)
• Missing branch protection (repos that should have protection rules but don't)

Running an Access Audit

Trigger an audit for one org:

1. Navigate to Organizations and click on the org
2. Click Run Access Audit
3. The audit collects data from the GitHub API in parallel and completes in 30–90 seconds
4. Results appear on the Access Audit page for that org

View audit history:

Navigate to Organizations → [Org Name] → Access Audits to see past audits. You can compare the current audit to previous ones to spot changes.

Understanding the Audit Report

The audit report contains several sections:

Summary — High-level numbers: total members, external collaborators, teams, drift issues, and a risk score from 0–100.

2FA Compliance — Percentage of members with 2FA enabled and the list of non-compliant members. For compliance frameworks, this is often a required control.

Permission Drift — Each drift finding shows:

• The repository affected
• The type of issue (over-privileged, orphaned access, admin sprawl, missing protection)
• Severity (critical, high, medium, low)
• Current state and recommended state
• Specific description of the problem

External Collaborators — Every user with repo-level access who is not an org member. External collaborators are a common source of excessive access, especially when contractors finish projects and aren't removed.

Teams — A table of every team with member count, repo access count, and permission level. Look for teams with broad admin permission — these should be narrow.

Permission Drift Issue Types

Type	Description
over_privileged	A user or team has admin or maintain access where read/write would suffice
orphaned_access	A user has repo access but is no longer an active org member
admin_sprawl	More than 2–3 org admins (excessive blast radius if one account is compromised)
missing_protection	A repository with no branch protection rules on the default branch

Cross-Org Access Dashboard

Navigate to Access Audit from the left sidebar to see an aggregate view across all organizations:

• Combined member count
• Combined external collaborator count
• Total drift issues by severity
• 2FA compliance percentage across all orgs
• Combined risk score

This is useful for QBR presentations — you can show a client how their access posture trended from one quarter to the next.

Escalating to PSA

When an access audit finds critical or high-severity drift issues, you can create a PSA ticket directly:

1. On the access audit report, find the drift issue
2. Click Create Ticket
3. The ticket is pre-populated with the issue type, description, affected repository, and remediation steps
4. Select priority and assignee
5. Click Create

The ticket appears in PSA and is linked back to the finding. When the ticket is resolved, you can mark the finding as remediated in The One Code.