On April 14, 2026, GitHub made Code Security Risk Assessment freely available (GitHub Blog). This tool visualizes vulnerabilities across all repositories within an organization in a single click, making a major impact by offering this visibility at no cost.
During the same period, supply chain attacks have surged, highlighted by critical vulnerabilities in Movable Type, simultaneous backdoors injected across 30 WordPress plugins, and compromised Axios build tools. Over the past year, engineering leaders have faced an unprecedented spike in executive inquiries asking, “Is our codebase secure?”
In this article, we cover how to leverage Code Security Risk Assessment as an effective audit tool for contract development and internal system maintenance.
Key takeaways of Code Security Risk Assessment
Here are three key highlights from GitHub's announcement:
- Batch scanning across all repositories at the organization level, returning results in minutes even for large organizations with over 100 repositories
- Classifying vulnerabilities into Critical, High, Medium, and Low, ranking priorities using a risk score that factors in remediation difficulty and exposure level
- Available on free plans, enabling situational awareness without requiring paid upgrades
While individual tools like Dependabot and CodeQL existed previously, providing an out-of-the-box dashboard suitable for presenting to executive leadership represents a major milestone.
3 scenarios where unseen vulnerabilities emerge in contract development
Scenario 1: Long-term maintenance of past deliverables
Projects delivered 1 to 3 years ago often have unmaintained dependencies. If the runtime (Node, PHP, Ruby) has reached end-of-life (EOL), security patches for underlying OS and middleware packages will no longer apply.
Scenario 2: Repositories left behind by contractors and temporary staff
In environments with high staff turnover, organizations frequently accumulate orphaned repositories that no current team member understands. Risk Assessment maps these blind spots systematically.
Scenario 3: M&A and corporate subsidiary integrations
Immediately after merging GitHub organizations following an acquisition or restructuring, conducting a technical asset audit becomes mandatory. Generating a comprehensive vulnerability overview within minutes serves as a powerful asset during due diligence.
Execution steps — initial 30-minute code vulnerability audit
Step 1: Open the Security tab in your organization
- Navigate to the target organization on GitHub
- Select Security → Code Security Risk Assessment
- Click “Start assessment”
Organization Owner or Security Manager permissions are required.
Step 2: Define scan scope
- Select from all repositories, active repositories only, or a custom list
- Toggle between private and public repositories
- Exclude archived repositories (recommended default: ON)
For the initial run, we recommend limiting the scope to active repositories.
Step 3: Review the assessment report
After a few minutes, four reporting views will be displayed:
| View | Application |
|---|---|
| Overall Risk Score | Organization-wide relative risk (executive summary) |
| Repository Breakdown | Vulnerability count and severity by repository |
| Top CVE List | Top 10 highest-impact CVEs across the organization |
| Dependency Graph | Vulnerable dependencies and where they are used |
Step 4: Prioritization
Address vulnerabilities sitting at the intersection of “Critical, actively running in production, and publicly exposed” first. Using the triage framework below ensures consistent decision-making.
Prioritization — the triad of remediation effort, exposure, and severity
You do not need to resolve every vulnerability immediately; rigorous triage is the fundamental rule.
| Severity | Exposure (production/public) | Remediation effort | Recommended action |
|---|---|---|---|
| Critical | High | Low to medium | Immediate remediation (same day) |
| Critical | High | High | Emergency patch + explore interim workarounds |
| High | High | Low | Weekly remediation |
| High | Low (internal only) | Medium | Monthly remediation |
| Medium | High | Low | Monthly remediation |
| Medium | Low | Medium | Quarterly remediation |
| Low | Low | High | Batch together during next scheduled refactor |
Just like with our Complete SSL Certificate Guide and Web Accessibility Compliance Guide, security is fundamentally about “what to fix first” rather than “fixing everything at once”.
Integrating security audits into contract deliverables
Proposal phase
- Explicitly include “3-month post-delivery vulnerability assessment report” in project proposals
- Incorporate quarterly Risk Assessment runs into ongoing maintenance agreements
- Prepare a standardized periodic reporting template for clients
Development phase
- Integrate Dependabot, CodeQL, and Secret Scanning into CI workflows
- State in PR templates: “Pin dependency versions upon addition, update via Renovate or Dependabot”
- Combine with GitHub Stacked PRs for small, rapid merges to accelerate security patching
Maintenance phase
- Execute monthly organization-wide scans and generate client summary reports
- Establish a first-response SLA (notification within 24 hours) upon discovering Critical vulnerabilities
- Propose annual platform modernization roadmaps on 3-to-5-year cycles
Client communication tips — translating technical risk for executives
Vulnerability findings resonate easily with engineers, but often fail to convey urgency to executive leadership. Standardizing explanations using the following framing is highly effective:
| Technical term | Executive-friendly translation |
|---|---|
| Critical vulnerability | “A high-risk security flaw with an extremely high probability of unauthorized external access.” |
| Vulnerability in a third-party dependency | “A defect discovered in a component supplied by an external parts manufacturer.” |
| EOL runtime | “Operating on an operating system or platform whose vendor support has officially ended.” |
| Supply chain attack | “An attack executed through a trusted partner or supplier channel.” |
| SBOM | “An ingredient list (an inventory documenting every component in use).” |
As discussed in our article on Responding to Movable Type Vulnerabilities and CMS Migration, deciding between patching and re-platforming is an executive business decision, making clear, business-oriented terminology essential.
Summary — how a free tool lowered the barrier to situational awareness
Making Code Security Risk Assessment free means that the barrier to entry for security assessments is now effectively zero. Contract development and in-house teams should focus on these three priorities:
- Incorporate quick audits into monthly routines (takes only 30 minutes)
- Share triage frameworks to clarify what gets patched first (do not attempt to fix everything at once)
- Provide an executive translation layer (never deliver raw technical jargon directly to leadership)
At GleamHub, we offer a comprehensive Web Security Audit Package covering code vulnerability assessments for client deliverables and legacy systems. From running initial organization scans and establishing severity-based roadmaps to drafting executive reports, our team is available starting with a two-week focused audit program. Auditing codebases that have been left unmonitored for years offers the highest return on investment for any security initiative.
