docs: Add githib vuln scanning design doc

Signed-off-by: Ronald Caesar <github43132@proton.me>
This commit is contained in:
Ronald Caesar 2025-09-21 18:36:28 -04:00
parent 3058e9992f
commit 8713dd751a
3 changed files with 56 additions and 4 deletions

3
.gitmodules vendored
View file

@ -1,6 +1,3 @@
[submodule "3rd_Party/fmt"]
path = 3rd_Party/fmt
url = https://github.com/fmtlib/fmt.git
[submodule "3rd_Party/SDL3"] [submodule "3rd_Party/SDL3"]
path = 3rd_Party/SDL3 path = 3rd_Party/SDL3
url = https://github.com/libsdl-org/SDL.git url = https://github.com/libsdl-org/SDL.git

1
3rd_Party/fmt vendored

@ -1 +0,0 @@
Subproject commit 40626af88bd7df9a5fb80be7b25ac85b122d6c21

View file

@ -0,0 +1,56 @@
**Design Document: GitHub-Native Vulnerability Scanning Strategy**
**Author:** GloriousTacoo, Lead Developer
**Status:** FINAL
**Version:** 1.0
**Date:** 2025-09-20
*Disclaimer: This document was mostly written by AI. I'm not a good technical writer.*
### **1. Problem Statement**
We require a comprehensive, automated vulnerability scanning system that operates entirely within GitHub's ecosystem. The Pound Virtual Machine project must continuously monitor for security vulnerabilities in both our own code and all third-party dependencies without introducing external tools or platforms. Given that GitHub is our sole available platform, we must maximize its native security capabilities to create a defense-in-depth approach that identifies, tracks, and remediates vulnerabilities throughout the development lifecycle. The challenge is to configure GitHub's security features to meet the rigorous standards expected of safety-critical systems while maintaining complete auditability and traceability of all security findings.
### **2. Glossary**
GitHub Advanced Security refers to GitHub's suite of security tools available for repositories, including code scanning, secret scanning, and dependency analysis. Dependabot is GitHub's automated dependency update tool that monitors for vulnerable dependencies and creates pull requests to update them. Code scanning is GitHub's static analysis tool that examines code for potential security vulnerabilities and coding errors. The Dependency Graph is GitHub's visualization of a repository's dependencies and their relationships. GitHub Advisory Database is GitHub's curated database of security vulnerabilities drawn from public sources like the Common Vulnerabilities and Exposures (CVE) list. Security alerts are notifications generated by GitHub when potential vulnerabilities are detected in code or dependencies.
### **3. Breaking Changes**
Implementing a comprehensive GitHub-native vulnerability scanning strategy will require immediate changes to our repository configuration and development workflow. All repository maintainers will need to enable GitHub Advanced Security features and configure the appropriate scanning rules. The existing codebase may require modifications to address any false positives or to ensure compatibility with the scanning tools. Development workflows must be updated to incorporate security review steps for all pull requests, with automated security checks becoming a mandatory part of the continuous integration process. All developers will require training on interpreting and responding to security alerts generated by GitHub's tools. These changes represent a fundamental shift in how we approach security throughout the development lifecycle and must be implemented comprehensively.
### **4. Success Criteria**
A successful GitHub-native vulnerability scanning strategy must achieve complete coverage of all code and dependencies, with no components excluded from automated analysis. The system must detect and report known vulnerabilities in third-party libraries within 24 hours of their public disclosure. All pull requests must undergo automated security scanning before merging, with critical security issues blocking integration until resolved. The scanning configuration must minimize false positives while maintaining a low threshold for detecting potential security issues. Security findings must be tracked through resolution, with clear metrics for time-to-detection and time-to-remediation. The entire security scanning process must be transparent and auditable, with all findings and remediation actions documented in GitHub's interface.
### **5. Proposed Design**
Our security philosophy must be that vulnerability scanning is not a periodic audit but a continuous, automated process integrated into every stage of development. GitHub's native security tools will be configured to operate with maximum sensitivity, erring on the side of over-reporting rather than missing potential issues. The scanning will operate at multiple levels: static analysis of our own code, dependency analysis of third-party libraries, and secret detection to prevent accidental exposure of sensitive information. All security findings will be treated as critical defects requiring immediate attention, with established workflows for triage, remediation, and verification. The system will leverage GitHub's integration between development and security tools to create a seamless security experience that doesn't impede development while maintaining rigorous security standards.
### **6. Technical Design**
The implementation will center on enabling and configuring GitHub Advanced Security across the Pound repository. Dependabot will be configured to monitor all third-party dependencies, with automated security alerts enabled and update pull requests automatically generated for vulnerable packages. GitHub's code scanning will be activated using the default security queries plus custom queries tailored to our specific codebase and potential vulnerabilities in virtualization systems. The dependency graph will be enabled to provide visibility into our entire dependency ecosystem, including transitive dependencies. Secret scanning will be activated to detect accidental commits of credentials, API keys, or other sensitive information. All security features will be configured to operate in the most stringent mode, with no exceptions granted for any components of the codebase.
### **7. Components**
The GitHub-native vulnerability scanning system consists of several integrated components working together to provide comprehensive security coverage. Dependabot forms the first line of defense by continuously monitoring our dependencies against the GitHub Advisory Database and creating automated pull requests when vulnerabilities are detected. GitHub code scanning provides static analysis capabilities that examine our source code for potential security vulnerabilities, coding errors, and deviations from security best practices. The dependency graph offers a visual representation of all dependencies in the project, including their relationships and versions, enabling better understanding of our attack surface. Secret scanning monitors all code changes for potentially sensitive information that should not be committed to the repository. GitHub's security tab serves as the central dashboard for managing all security findings, providing a unified view of alerts, dependencies, and code scanning results.
### **8. Dependencies**
This vulnerability scanning strategy depends entirely on GitHub's Advanced Security features being enabled and properly configured for the repository. The repository must be configured to allow GitHub Advanced Security, which may require specific licensing or organization settings. The development team must have appropriate permissions to view and act on security alerts, with clear processes established for responding to different types of security findings. The codebase must be structured in a way that is compatible with GitHub's scanning tools, with clear separation between first-party and third-party code. Regular maintenance of the scanning configuration is required to ensure it remains effective as the codebase evolves and new security threats emerge.
### **9. Major Risks & Mitigations**
The primary risk is that GitHub's security tools may generate false positives that could potentially block legitimate development work if not properly managed. This will be mitigated through careful configuration of the scanning rules and establishment of a triage process to quickly evaluate and address false positives. Another significant risk is that the scanning may miss vulnerabilities that are specific to virtualization systems or ARM64 architecture, as GitHub's default queries may not cover these specialized domains. This will be addressed by developing custom code scanning queries tailored to our specific technology stack and potential vulnerabilities. There is also a risk that developers may become overwhelmed by security alerts if the initial configuration is too sensitive, leading to alert fatigue and potentially ignoring legitimate issues. This will be countered by implementing a phased approach to enabling security features, starting with the most critical checks and gradually expanding coverage as the team becomes more comfortable with the tools.
### **10. Out of Scope**
This strategy does not cover the manual security review of code, which remains an essential complement to automated scanning. The approach does not address penetration testing or other forms of dynamic security analysis, which would require external tools beyond GitHub's ecosystem. The strategy does not provide guidance on responding to security incidents or breaches, as those procedures are covered by separate incident response plans. The training of developers on secure coding practices is considered essential but is not specifically addressed here. The strategy also does not cover the legal or compliance aspects of vulnerability disclosure, which would require separate processes and procedures.
### **11. Alternatives Considered**
The primary alternative considered was using external security scanning tools such as SonarQube, Checkmarx, or Snyk, which would provide more specialized or comprehensive scanning capabilities. However, these alternatives were rejected because they would require additional infrastructure, licensing, and maintenance beyond our GitHub-only constraint. Another alternative was to develop custom security scanning scripts or tools, but this approach was deemed too resource-intensive and less effective than leveraging GitHub's mature security ecosystem. Manual security reviews were considered as a supplement but rejected as a replacement for automated scanning due to their inconsistency and inability to provide continuous coverage. Each of these alternatives was ultimately deemed unsuitable given our constraint to use only GitHub's capabilities.
### **12. Recommendation**
After thorough evaluation of available options within GitHub's ecosystem, implementing a comprehensive configuration of GitHub Advanced Security represents the optimal approach for vulnerability scanning in the Pound project. This strategy leverages GitHub's native capabilities to provide continuous, automated security monitoring without requiring external tools or platforms. The implementation should begin immediately with the enablement of GitHub Advanced Security features, followed by careful configuration of Dependabot, code scanning, secret scanning, and the dependency graph. Custom code scanning queries should be developed to address vulnerabilities specific to virtualization and ARM64 systems that may not be covered by GitHub's default queries. All developers must be trained on the new security workflow and their responsibilities in responding to security alerts. This approach provides the best possible security coverage within our GitHub-only constraint while maintaining the rigorous standards expected of a safety-critical system.