GitHub Enterprise Server STIG Compliance: A Practical Checklist
I've sat through enough STIG audits to know which findings keep coming up. Here's the checklist I wish I'd had the first time.
Why STIG Compliance Matters for GHES
Look, if you're running GHES on a classified network, you already know the drill. Your developers want the same collaboration tools they'd have on the commercial internet. Your security team wants everything locked down. And somewhere in the middle, you're trying to get an ATO.
The thing about GHES is that it's an appliance. You can't just SSH in and start tweaking MySQL configs or hardening the OS like you would with a regular server. GitHub controls the internals. That's actually a feature—it means less attack surface for you to worry about—but it also means your compliance approach needs to focus on what you can control.
While there isn't a GitHub-specific STIG (as of this writing), your GHES instance will need to comply with:
- • Application Security and Development STIG — General requirements for application security
- • Web Server STIG — GHES runs on nginx internally
- • Operating System STIG — The underlying VM (typically RHEL-based)
- • Database STIG — GHES uses MySQL and Elasticsearch internally
The practical challenge is that GHES is an appliance—you don't have full access to the internals. You can't just SSH in and start modifying MySQL configs. This guide focuses on what you can control through the Management Console, ghe-config, and administrative settings.
Authentication Controls
Authentication is where most federal GHES audits focus first. The goal: no local accounts, centralized identity management, and multi-factor authentication.
SAML Single Sign-On
- ☐ Enable SAML SSO via Management Console → Authentication
- ☐ Configure your IdP (ADFS, Okta, Azure AD, Ping) with appropriate attribute mappings
- ☐ Ensure NameID format matches your user principal format
- ☐ Test with a non-admin account before enforcing for all users
- ☐ Document the SAML trust relationship for your SSP
Built-in Authentication Hardening
- ☐ Disable built-in authentication if using SAML exclusively
- ☐ If built-in auth is required, enforce strong password policy via
ghe-config - ☐ Set minimum password length:
ghe-config app.github.minimum-password-length 14 - ☐ Audit and remove any dormant local accounts quarterly
SSH Key Management
- ☐ Require SSH key approval by organization owners
- ☐ Enforce SSH key expiration: Site Admin → Policies → SSH keys
- ☐ Disable weak key algorithms (DSA keys should be blocked)
- ☐ Require minimum RSA key length of 2048 bits (preferably 4096 or Ed25519)
Personal Access Tokens
- ☐ Enforce PAT expiration policy at the enterprise level
- ☐ Require fine-grained PATs over classic tokens where possible
- ☐ Audit PAT usage via the audit log for tokens accessing sensitive repos
- ☐ Document PAT lifecycle management procedures
Audit Logging Configuration
Federal systems require comprehensive audit logging. GHES provides extensive audit capabilities, but you need to configure log forwarding and retention appropriately.
Audit Log Streaming
- ☐ Enable audit log streaming to your SIEM (Splunk, Elastic, Azure Sentinel)
- ☐ Configure syslog forwarding: Management Console → Monitoring → Syslog
- ☐ Use TLS for syslog transport (not UDP)
- ☐ Verify logs are reaching the SIEM and being parsed correctly
What to Log
Ensure your audit log configuration captures:
- ☐ All authentication events (success and failure)
- ☐ Repository access events (clone, push, pull)
- ☐ Administrative actions (user creation, permission changes)
- ☐ Organization and team membership changes
- ☐ SSH key additions and removals
- ☐ Webhook and integration configuration changes
Retention Requirements
- ☐ Configure SIEM retention to meet your system's requirements (typically 1-7 years)
- ☐ Note: GHES on-appliance audit log retention is limited; rely on external storage
- ☐ Document your log retention policy in the SSP
TLS and Network Configuration
All communications with GHES must be encrypted. This includes user access, API calls, and git operations.
TLS Certificate Configuration
- ☐ Install a certificate from your organization's PKI (not self-signed)
- ☐ Use RSA 2048+ or ECC P-256+ key for the certificate
- ☐ Include full certificate chain in the configuration
- ☐ Set certificate expiration monitoring alerts
Protocol Hardening
- ☐ Disable TLS 1.0 and 1.1 (require TLS 1.2 minimum, prefer 1.3)
- ☐ Via ghe-config:
ghe-config app.github.ssl-protocols 'TLSv1.2 TLSv1.3' - ☐ Disable weak cipher suites
- ☐ Test with SSL Labs or similar to verify configuration
Subdomain Isolation
- ☐ Enable subdomain isolation: Management Console → Hostname
- ☐ This isolates user content (GitHub Pages, avatars) to subdomains
- ☐ Helps prevent cookie-based attacks across the application
Common Misconfigurations That Fail Audits
Based on our experience with federal GHES deployments, these are the issues that most commonly cause audit findings:
Frequent Audit Failures
- ✗ Ghost admin accounts: The initial setup creates a local admin. If you've moved to SAML, this account often remains active and unmonitored.
- ✗ SSH keys without expiration: Users add SSH keys and forget about them. Without expiration, keys from former employees may remain valid.
- ✗ Audit logs not forwarded: Relying only on the GHES web UI for audit log review doesn't meet retention requirements.
- ✗ TLS 1.0/1.1 still enabled: Default configurations may allow deprecated protocols.
- ✗ Anonymous Git access: Ensure all repositories require authentication, even for read access.
- ✗ Unpatched instances: GHES releases security updates regularly. Being more than one version behind is a finding.
Automation Approaches
Manual STIG compliance checking doesn't scale. Here are automation patterns that work for GHES:
Ansible for Baseline Hardening
While you can't modify GHES internals directly, you can automate configuration via the Management Console API and ghe-config:
# Example: Ansible task to enforce TLS configuration
- name: Configure TLS protocols
command: ghe-config app.github.ssl-protocols 'TLSv1.2 TLSv1.3'
delegate_to: "{{ ghes_host }}"
- name: Apply configuration
command: ghe-config-apply
delegate_to: "{{ ghes_host }}" API-Based Compliance Monitoring
Use the GHES Admin API to continuously monitor for drift:
- • Query user accounts: Identify users without SAML linkage
- • Enumerate SSH keys: Find keys approaching expiration or using weak algorithms
- • Check organization settings: Ensure consistent security policies across orgs
- • Monitor for public repositories: Alert if any repo is set to public (unusual in federal)
Integration with Compliance Scanning
For the underlying VM (if you have access):
- • Run SCAP scans against the RHEL STIG on the host OS
- • Note: Some findings will be "Not Applicable" due to appliance constraints
- • Document compensating controls for findings you can't remediate
Ongoing Compliance Monitoring
STIG compliance isn't a one-time event. Build these practices into your operations:
Weekly Tasks
- ☐ Review audit logs for anomalous authentication patterns
- ☐ Check for new GitHub security advisories affecting your version
- ☐ Review any new SSH keys or PATs added
Monthly Tasks
- ☐ Run automated compliance scan and compare to baseline
- ☐ Verify backup integrity and test restore procedures
- ☐ Review and prune dormant user accounts
- ☐ Validate that log forwarding is functioning correctly
Quarterly Tasks
- ☐ Full STIG assessment with documented findings
- ☐ Review and update compensating controls documentation
- ☐ Plan upgrade path for upcoming GHES releases
- ☐ Review certificate expiration dates
Documentation Requirements
Your ATO package will need documentation beyond just the technical configuration:
- • System Security Plan (SSP): How GHES fits into your overall security architecture
- • Security Assessment Report (SAR): Results of STIG compliance testing
- • Plan of Action and Milestones (POA&M): For any findings requiring compensating controls
- • Continuous Monitoring Plan: How you'll maintain compliance over time
- • Incident Response Procedures: Specific to the GHES environment
Need Help Getting Your GHES Instance Audit-Ready?
We specialize in GitHub Enterprise deployments for federal environments. From initial hardening to continuous compliance monitoring, we can help you achieve and maintain your ATO.
Get in TouchRelated Reading