Invoke Change with GitHub CodeQL and Tromzo
This is part three of our GitHub series, where we have covered GitHub and Application Security, GitHub Dependabot, and now GitHub CodeQL. Following this blog, we will cover GitHub Secret Scanner. Some additional resources that might be helpful are the two blogs How GitHub Uses Dependabot and What are Software Dependencies. Let’s dive into CodeQL!
CodeQL, a really cool semantic code analysis engine and query tool for finding security vulnerabilities across a codebase, as part of GitHub Advanced Security.
CodeQL queries code as if it were data so that developers can write queries that can identify variants of vulnerabilities, and then share that query with other developers. A great example of this is that a developer could write a query that mimics a bug class for cross-site scripting, then use that query to find any bug class. CodeQL also can be used to find zero days, variants of critical vulnerabilities, and defects such as buffer overflows or SQL injection issues.
Some features of CodeQL include:
- Libraries for control and data flow analysis, taint tracking, and threat model exploration.
- CodeQL plug-ins to IDEs.
- The LGTM query console, which can be used to write CodeQL in a browser and query a portfolio for vulnerabilities.
- The ability to run out-of-the-box queries or custom queries on multiple codebases.
The CodeQL command-line interface (CLI) is used to create databases for security research and allow users to query CodeQL databases directly from the command line. So you can:
- Run CodeQL using queries provided by the open source community.
- Create CodeQL databases to use in the CodeQL for Visual Studio Code.
- Develop and test custom CodeQL queries to use in your own analyses.
The CodeQL CLI includes commands to create and analyze CodeQL databases from the command line. To run a command, use:
codeql [command] [subcommand]
This CLI can then be used in Github Actions Workflow to add code scanning to Github repositories.
Code Scanning with CodeQL
Code scanning with CodeQL allows you to analyze the code in a GitHub repository to find security vulnerabilities and coding errors so your developers can find, triage, and prioritize fixes for existing problems. Once the scanning is configured, anyone with read permissions to a repository can view the resulting alerts on pull requests. Also, the security view within GitHub code repository shows you all the security alerts, including those identified from code scanning.
Some other really cool things about code scanning with CodeQL that we are excited about are:
- Pull Request Hash – the results automatically have a pull request hash associated with them to allow your development and security team to do vulnerability tracing.
- Packs – CodeQL packages can contain CodeQL queries and CodeQL libraries and dependencies between packs. The really amazing part of it is that you can upload packs to the package registry on GitHub.com, and CodeQL will automatically fetch any required dependencies when running queries from a pack. This makes it simple to create and share CodeQL queries and libraries.
- Query packs – which contain a set of pre-compiled queries that can be easily evaluated on a CodeQL database.
- Library packs – which contain CodeQL libraries (*.qll files), but do not contain any runnable queries. Library packs are meant to be used as building blocks to produce other query packs or library packs.
- State Management – users can view, fix, or dismiss alerts for potential vulnerabilities or errors in a project’s code. What does this mean? Well, it means your developers can quickly and efficiently dismiss potential vulnerabilities as a false positive, won’t fix, or used in tests (ie. not in production code). This allows for your developers to triage alerts versus allocating the minimal security resources you have to triaging.
GitHub CodeQL and Tromzo
GitHub is a phenomenal platform for developers, however security teams also need to solve additional use cases:
- A holistic view of all software assets and associated vulnerabilities 👓
- Ensure that every important repo has CodeQL enabled and if dev teams are actually triaging/fixing things 🔧
- Ability to create and route tickets at scale 🛣️
- Group similar bugs into consolidated tickets 🐞
- Assign bugs to the right team or person that owns the code repos 🧍
- Measure and report KPIs like MTTR, SLA compliance, etc. 〽️
This is where Tromzo can help operationalize CodeQL at scale with a unified Product Security Operating Platform (PSOP) to enable:
- Centralized Visibility – aggregates all code repos across multiple source control systems as software assets along with metadata like which repos have scan coverage from CodeQL. This centralization of business context, alongside consolidation with vulnerability data from other security scanners (SAST, DAST, IaC Scanners, etc) gives a real time and deduplicated view of security risk across code repos.
- Security Guardrails – automatically implement guardrail to ensure only the critical code repos or all repos should have CodeQL enabled. In complex enterprise environments, it is not feasible to make enterprise wide changes and enforce Dependabot and CodeQL on every single repo. Tromzo’s Security Guardrails allows you to implement security requirements like enabling CodeQL on specific repos that are important to your business and / or in scope for compliance. For code repos missing coverage, Tromzo can automate action in Pull Requests or notify using out of band channels like Slack, Jira, Email etc. This truly helps the security teams ensure every single code repo that is important to the business, has Dependabot and CodeQL enabled without any manual intervention from the security team.
- Workflow Automation – automatically triage, prioritize and consolidate vulnerabilities into actionable alerts. For example, you can;
- Automate the routing of tickets to the right teams.
- Consolidate vulnerabilities (like XSS) in the same file, multiple places – same bug, same code repo, and aggregate as unique alerts – focus on what is actually important.
Automate prioritization and deprioritization so your development team can focus on particular classes of bugs. Some of our customers have a focus on injection attacks and that gets classified as higher priority over other bugs.
- Deprioritize certain bugs that are identified as systemic issues that are not relevant to an organization or there are other mitigating controls in other parts of the stack so the development team doesn’t need to focus on them.
- Enforce governance with automated due dates with identification of the severity of the alert and automatically assign SLAs based on severity. Additionally, our customers have customizable policies to address bug classes that need a non-standard SLA.
- With a two-way sync with Jira, Tromzo can automate the creation of a tickets in Jira Projects of the development teams that own those code repos and route tickets to the right projects based on code ownership. Additionally, bug status changes from CodeQL are also synchronized across Jira and other task tracking systems.
- Reporting & Analytics – enables central teams like product security or application security to enrich security risk with code ownership and clearly communicate the risk owned by various development teams or services. Measuring KPIs like MTTR, SLA Compliance, Remediation Rates and reporting them per team with leaderboards, is instrumental in driving ownership and accountability of risk across the organization. Additionally, the security team can look at categories of vulnerabilities to see what the most common classifications of bugs are by business unit, organization, etc.
Additionally, in this series of how Tromzo can help with visibility and control within GitHub, we have covered and will be covering:
GitHub and Application Security, GitHub Dependabot, and GitHub Secret Scanner
If you want to learn more about how Tromzo can help, we would love to hear from you: https://www.tromzo.com/github-demo