GHAS - It Protects supply chain, code and environments of an orgnzn

1. Introduction to GHAS

1.1. Features

1.1.1. Secret Scanning

1.1.1.1. Automatically scans for secrets

1.1.2. Code Scanning

1.1.2.1. By providing automated feedback directly within the pull request workflow, code scanning enables developers to address vulnerabilities early in the development process.

1.1.3. Dependabot

1.1.3.1. Automates dependency management

1.1.4. Creating secure SDLC with all 3 features

1.1.4.1. Early detection

1.1.4.2. Efficient remediation

1.1.4.3. Consistent security standards

1.1.4.4. Improved collaboration

1.1.4.5. Automated security checks are run **with every pull request,** surfacing issues in the context of the development workflow so vulnerabilities are fixed in minutes, not months.

1.2. Open source or public repos created by us

1.2.1. By default secret scanning and dependency graphs

1.2.2. Manually enable code scanning, dependabot, dependabot alerts, dependency review without license

1.2.3. GHAS+GHEC-Enterprise Cloud

1.3. What plan you are on

1.3.1. Main settings > Billing and plans > Plans and usage > Compare all plans > You get comparision between different features

1.3.1.1. Enabling GHAS

1.3.1.1.1. Personal/Individual level

1.3.1.1.2. Organization level

1.3.1.1.3. Repository level

1.3.1.1.4. Pro or enterprise plan level

2. GHAS Best Practices

2.1. Manage Sensitive Data and security policies in github

2.1.1. Security Policies

2.1.1.1. Community Health Documentaion files (default) - org/user level

2.1.1.1.1. README.md

2.1.1.1.2. CODE_OF_CONDUCT.md

2.1.1.1.3. CONTRIBUTING.md

2.1.1.1.4. SUPPORT.md

2.1.1.1.5. GOVERNANCE.md

2.1.1.1.6. FUNDING.yml

2.1.1.1.7. Discussion category forms

2.1.1.1.8. Issue and pull request templates and config.yml

2.1.1.1.9. SECURITY.md

2.1.1.2. Built-in Security Settings and Features at org / enterprise level - Org policies / Enterprise policies

2.1.1.2.1. User permissin settings

2.1.1.2.2. Automation of some common security tasks

2.1.1.2.3. Most significant manual interaction

2.1.1.2.4. Features available for all repos

2.1.1.3. Security Advisories

2.1.1.3.1. Used when vuln found in published code

2.1.1.3.2. check if your vuln patching matches a CVE or CWE

2.1.1.3.3. Admins publish them

2.1.1.3.4. A security advisory includes comprehensive details of

2.1.1.3.5. historical

2.1.1.4. Setting Security Policies

2.1.1.4.1. Maintain the health of your github repos

2.1.1.4.2. To limit permissions to collaborators and help assist them incase they discover a security threat

2.1.1.4.3. Levels

2.1.2. Repository Rulesets

2.1.2.1. Control how users can interact with certain branches and tags in a repository

2.1.2.1.1. limit of 75 rulesets per repository.

2.1.2.2. Rulesets work alongside branch-protection and tag-protection rules, allowing you to have fine-grained control over your repository's behavior.

2.1.2.2.1. No need to override them

2.1.2.2.2. you can import existing tag protection rules into repository rulesets

2.1.2.3. E.g.: You could set up a ruleset for your repository's feature branch that requires signed commits and blocks force pushes for all users except repository administrators

2.1.2.4. Advantages

2.1.2.4.1. Unlike protection rules, multiple rulesets can apply at the same time, ensuring all rules for a branch or tag are checked when interacted with.

2.1.2.4.2. Ruleset statuses allow easy management of active rulesets without needing to delete them.

2.1.2.4.3. Anyone with read access can view active rulesets, helping developers understand why they have hit a rule, or an auditor can check the security constraints for the repository, without requiring admin access to the repository.

2.1.2.5. Creation

2.1.2.5.1. Settings > Code and automation > Rules > Rulesets - Enter configurations

2.1.2.6. Management

2.1.2.6.1. Edit/monitor/Delete rulesets

2.1.2.6.2. Temporarily disable for troubleshooting

2.1.2.6.3. View access helps in knowing why you cant commit to a branch

2.1.2.6.4. Certain set of default rules exist for branches and tags and you need to select what you want

2.1.2.6.5. Custom rules cannot be created

2.1.2.7. Layering Rules

2.1.2.8. Rulesets for orgnzns on Enterprise plan

2.1.2.8.1. Quickly set up rulesets at the organization level to target multiple repositories in your organization.

2.1.2.8.2. Create additional rules to control the metadata of commits entering a repository, such as the commit message and the author's email address.

2.1.2.8.3. Use an Evaluate status to test a ruleset before making it active, and use an insights page to view which user actions are being affected by rules.

2.1.3. Reporting and Logging

2.1.3.1. Log records

2.1.3.1.1. The repository in which the action was performed.

2.1.3.1.2. The user that performed the action.

2.1.3.1.3. The action that was performed.

2.1.3.1.4. Which country/region in which the action took place.

2.1.3.1.5. The date and time of the action.

2.1.3.2. Access logs from past 90 days through

2.1.3.2.1. github.com

2.1.3.2.2. github enterprise server

2.1.3.2.3. github AE

2.1.3.2.4. easy ways

2.1.3.3. Exporting logs

2.1.3.3.1. Only for Enterprise accounts on UI

2.1.3.3.2. Settings > Audit log > Export (JSON/CSV) , Export GitEvents

3. Github Administration for GHAS

3.1. GHAS features

3.1.1. GHAS in SDLC

3.1.1.1. Security Policies

3.1.1.1.1. Project configuration for access

3.1.1.1.2. Security team

3.1.1.2. Secret Scanning

3.1.1.2.1. Every commit and merge

3.1.1.2.2. Security team

3.1.1.3. Dependabot

3.1.1.3.1. Always ON once enabled

3.1.1.3.2. Security team

3.1.1.4. Dependency Review

3.1.1.4.1. Always ON once enabled

3.1.1.4.2. Security team

3.1.1.5. Code Scanning

3.1.1.5.1. Every commit and merge

3.1.1.5.2. Testing

3.1.1.5.3. Security team

3.1.1.6. Roles & Responsibilities example

3.1.1.6.1. Developer Roles

3.1.1.6.2. Security Roles

3.1.1.6.3. Admin Roles

3.2. Enabling GHAS for all repos in an orgnzn on Enterprise level

3.2.1. Enterprise cloud

3.2.1.1. Settings> Code security> GHAS-Enable all > Automatically enable for new repos

3.2.1.2. Enabling GHAS at orgnzn level automatically turns on GHAS for all private and internal repos in an orgnzn

3.2.1.3. If you enable GHAS in an orgnzn, **commiters ** to the orgnzn repos will use seats on available GHAS license

3.2.2. Enterprise Server

3.2.2.1. Enable Advanced security for your GitHub enterprive server instance first by using

3.2.2.1.1. Github UI

3.2.2.1.2. Administrative shell (SSH) and command-line utilities for GitHub Enterprise Server

3.2.2.1.3. Prerequisites

3.2.2.2. Orgnzn level

3.2.2.3. Enabling GHAS features on your Enterprise Server instance will cause user-facing services on GitHub Enterprise Server to restart. You should time this change carefully to minimize downtime for users.

3.3. Manage access to GHAS

3.3.1. Manage access to security alerts to view and resolve them

3.3.1.1. Minimum roles and permissions needed to view alerts in Security tab

3.3.1.1.1. Code scanning alerts - Write permission on repository

3.3.1.1.2. Secret scanning alerts - Repository administrators and organization owners

3.3.1.1.3. Dependabot alerts - Repository administrators and organization owners

3.3.1.1.4. Repo admins and orgnzn owners can give secret scanning and Dependabot alert access to users and teams with write permission on their repositories from the repository Security and analysis settings

3.3.1.2. What developers can do

3.3.1.2.1. For code scanning alerts: commit corrections to the code, dismiss alerts that don't require any action, or delete alerts to clean up code scanning results.

3.3.1.2.2. For secret scanning alerts: delete detected secrets, create new tokens, and update code that uses the detected secrets, or dismiss alerts that don't require any action.

3.3.1.2.3. For Dependabot alerts: update vulnerable dependencies or dismiss alerts that don't require any action.

3.3.2. Set a security **policy ** at the organization level

3.3.2.1. good way

3.3.2.2. Enterprise sidebar > Policies > Advanced security > GHAS > select a policy

3.3.2.3. GitHub bills for Advanced Security on a per-committer basis when setting up a policy at the organization level.

3.3.3. Set a security **policy ** at the repository level

3.3.3.1. SECURITY.md file to the root, docs, or .github folders of the project repository

3.3.3.2. Security tab > Reporting > Policy > Edit the security.md file by adding supported versions of your project and how to report a vuln > Commit the change to repo

3.4. Manage access to GHAS features and alerts

3.4.1. Security Overview in Security tab - Security > Overview

3.4.1.1. Reviews the security configuration and alerts for an organization and identifies the repositories at greatest risk

3.4.1.2. high-level view of the project's security status/overall security landscape of github orgnzn and summary of alerts

3.4.1.2.1. At the organization level, the Security Overview displays aggregate and repository-specific security information for repositories owned by your organization. You can also filter information per security feature.

3.4.1.2.2. At the team level, the Security Overview displays repository-specific security information for repositories that the team has admin privileges for.

3.4.1.2.3. At the repository level, the Security Overview shows which security features are enabled for the repository and offers the option to configure any available security features not currently in use.

3.4.1.3. lets administrators identify problematic repositories that require intervention.

3.4.1.3.1. You need owner or security manager permission to view security for all repos

3.4.1.4. Not available for public repos

3.4.2. Use GHAS Endpoints

3.4.2.1. Code scanning

3.4.2.1.1. Code Scanning API Endpoints

3.4.2.2. Secret Scanning

3.4.2.2.1. Repos API and Secret Scanning API Endpoints

3.4.2.3. Dependency review

3.4.2.3.1. Repos API and GraphQL API Endpoints

3.4.2.4. Correctly set the permissions for the GITHUB_TOKEN used to make authenticated API calls to automate your security workflows

3.4.2.4.1. Use permissions key

3.5. Logs

3.5.1. Provides audit insights into what actions were performed by users and amins across

3.5.1.1. Orgnzn level

3.5.1.1.1. Audit logs

3.5.1.1.2. Sponsorship logs

3.5.1.2. Personal account

3.5.1.2.1. Security log

3.5.1.2.2. Sponsorship log

3.6. Repository rules management

3.7. Private vulnerability reporting feature

3.7.1. Seen in Security Overview tab

4. Secret Scanning

4.1. Secret scanning- Continuous scan

4.1.1. Scanning repositories for known type of secrets/auth credentials like token, private keys, API keys, connection strings, authentication headers, passwords etc. patterns provided by Github and Github partners and custom patterns

4.1.1.1. Secret Scanning Github Partner Program

4.1.1.1.1. Partners (Service providers) provide regexes and verification endpoint to detect if secret is real

4.1.1.1.2. Partners : CSPs, NPM, Ruby, Postman, Hashicorp Terraform, Atlassian, Canva etc. E.g.: AWS provides AWS secret key

4.1.1.1.3. By default for public repos and public npm packages

4.1.1.1.4. private repos

4.1.1.2. Github docs has list of known secret scan patterns

4.1.2. Available for

4.1.2.1. Public repos

4.1.2.1.1. Settings>Security>Code security>Secret Protection-Enable

4.1.2.1.2. Free, Cannot be configured or turned off, Switch to private repo with GHAS if you want to change settings

4.1.2.1.3. Alerts can be enabled or disabled

4.1.2.2. Private Repos, Orgnzns with Github Teams and Github Enterprise

4.1.2.2.1. Organizations need GHAS license, to be manually enabled, can be done by github admins or repo admins

4.1.2.2.2. Exclude certain files or directories in a repo

4.1.2.2.3. Secret Risk Assessment

4.1.2.2.4. Sends a notification (that cabn be seen in Security tab > Vulnerability alerts > Secret scanning) about the commit that contains the secret

4.1.3. Alert Patterns

4.1.3.1. User alerts

4.1.3.2. Push protection alerts

4.1.3.3. Partner alerts

4.1.4. Secret_scanning.yml file contains?

4.1.4.1. paths to ignore

4.1.5. Scan locations

4.1.5.1. Entire git repo even if its archived

4.1.5.2. Automatically scan entire git history on all branches

4.1.5.3. Descriptions and comments in issues.

4.1.5.4. Titles, descriptions, and comments, in open and closed historical issues

4.1.5.5. Titles, descriptions, and comments in pull requests.

4.1.5.6. Titles, descriptions, and comments in GitHub Discussions

4.1.5.7. Wikis

4.1.6. Secret Scanning Notes

4.1.6.1. Not a one time activity

4.1.6.2. it continuously monitors new commits for exposed secrets.

4.1.6.3. It is automated scan and does not require manual triggering for each scan, though manual scans can also be initiated

4.1.6.4. automatically triggered whenever new commits are pushed to the repository, scanning the changes in those commits for potential exposed secrets but not on a fixed time schedule

4.2. Push protection

4.2.1. Secret scanning checks also for secrets along with existing project when this is enabled

4.2.1.1. blocks push if known secret is present

4.2.2. push is different and commit is different

4.2.2.1. You cannot prevent a user to commit a secret unless you have a local software to scna the code before commit (pre-commit)

4.2.2.2. You can prevent pushing a commit which contain a secret with push protection

4.2.3. Available for

4.2.3.1. Orgnzn with GHAS license at repo level/orgnzn level

4.2.3.2. Public repos-free

4.2.3.2.1. Settings>Security>Code security>Secret Protection-Enable>Push protection - Enable

4.2.4. Works from CLI, Github UI, github repos, rest API and it prompts in IDE incase of detection

4.2.4.1. Push Protection works in real-time, Secret Scanning does not

4.2.5. Customize

4.2.5.1. Configure delegated bypass and approval process

4.2.5.1.1. test file

4.2.5.1.2. false positive

4.2.5.1.3. fixing it latern by making it as a open alert

4.2.5.2. Custom patterns

4.2.5.3. Integrate with CI/CD

4.2.6. limitations

4.2.6.1. only first 5 secrets shown

4.2.6.2. >1000 secrets and push > 50 MB - push is not blocked

4.2.6.3. old versions of secret not supported

4.3. Validity checks for select tokens

4.3.1. whether a token is still active and, when possible, whether it was ever active.

4.3.1.1. Helps in prioritizing remediation

4.3.2. Default - Github tokens

4.3.3. Github teams and Github enterprise can enable validity checks for partner patterns

4.3.4. Repo settings > Advanced security> secret protection> validity checks - Enable. ENable using REST API also

4.4. Customize secret scanning-Github Team and enterprise orgnzn with GHAS license

4.4.1. Create custom patterns of the secret based on your organization

4.4.1.1. Not for public repos

4.4.1.2. Organization or enterprise account

4.4.1.2.1. 500 custom patterns

4.4.1.3. User's Private repository

4.4.1.3.1. 100 custom patterns

4.4.1.4. Private repo level

4.4.1.4.1. Settings > Code security and analysis >Secret scanning > Custom patterns >New pattern

4.4.1.5. Organization level

4.4.1.5.1. Same as above but additionally you can select repos to perform dry run

4.4.1.6. Non provider patterns such as private keys, aut headers

4.4.1.6.1. Settings>Advanced security> Secret protection> Non provider patterns-ENable

4.4.1.6.2. Push protection and validity checks are not supported for non-provider patterns.

4.5. Copilot AI Secret Scanning - no need of copilot subscription, GHAS license is enough

4.5.1. To detect unstrcuted secrets such as passwords

4.5.1.1. Max 100 passwords per push

4.5.1.2. Does not detect test or mock files

4.5.2. Generate regexes for custom patterns

5. Dependency management

5.1. 3 tools

5.1.1. Dependency graph

5.1.1.1. dependency graph supports a range of popular package ecosystems

5.1.1.2. Dep graph does not scan source code

5.1.1.3. Structure-to see what open source dependencies are in use in your project

5.1.1.3.1. Dependencies

5.1.1.3.2. Dependents

5.1.1.4. Available for

5.1.1.4.1. Public repos

5.1.1.4.2. Private repos

5.1.1.4.3. Forks, Archived repos

5.1.1.5. manifest (e.g., package.json, Gemfile) and lock files (e.g., package-lock.json, Gemfile.lock)

5.1.1.6. Where to view

5.1.1.6.1. Insights tab>Dependency graph> 3 tabs=Dependencies,Dependents,Dependabot

5.1.1.7. Used by section

5.1.1.7.1. number of public references to the package that were found

5.1.1.7.2. Your repo will have used by section in sidebar of code tab if

5.1.2. Dependabot

5.1.2.1. Used dependency graph and github advisory DB to provide 3 features

5.1.2.1.1. Dependabot Security updates

5.1.2.1.2. Dependabot Version updates

5.1.2.1.3. Dependabot Alerts

5.1.2.2. Supported package managers

5.1.2.2.1. composer (PHP)

5.1.2.2.2. nuget (.Net)

5.1.2.2.3. maven (Java/Scala)

5.1.2.2.4. npm (JavaScript)

5.1.2.2.5. PIP (Python)

5.1.2.2.6. Yarn (JavaScript)

5.1.2.2.7. RubyGems (Ruby)

5.1.2.2.8. Go modules (Go) - ONLY for GitHub Enterprise Security versions above 3.2

5.1.2.2.9. Python Poetry (Python) - ONLY for GitHub Enterprise Security versions above 3.3

5.1.2.3. Can/Cannot

5.1.2.3.1. can scan on Github Action

5.1.2.3.2. can only scan packages supported by dependency graph

5.1.2.3.3. can **alert ** based on github advisory database entries

5.1.2.3.4. cannot scan archived repos

5.1.2.3.5. cannot generate alert for malware

5.1.2.4. Limitations

5.1.2.4.1. All alerts to be reviewed whether they are TP/FP

5.1.2.4.2. Not all alerts would have a security patch so:depbot security update" is not a full proof plan especially if you dont have a secure upgrade or downgrade version

5.1.2.4.3. Limitation of languages supported by depbot limits the use case in case your organization uses a language not supported currently by dependency graph

5.1.2.4.4. If using private repositories, then advanced features of depbot need GHAS license

5.1.2.5. Enabled bydefault for public repos, manually enable bot and graph for private repos, forked repos, archived repos

5.1.2.5.1. Settings > Code security > Grant Dependabot access to private repositories

5.1.2.6. Manage Dependabot Notifications and reports

5.1.2.6.1. Admins get alerts in security tab if they are watching the repo, enanbled security notif alerts, enabled all activity on repo

5.1.2.6.2. Notifications

5.1.2.6.3. Admins can grant access to others to view alerts

5.1.2.6.4. security digest mail

5.1.2.6.5. **Triage**

5.1.2.6.6. GraphQL API to retrieve and export Dependabot alert information

5.1.2.7. Comment commands

5.1.2.7.1. @dependabot merge

5.1.3. Dependency review

5.1.3.1. Checks if a pull request introduces any dependencies with security vulnerabilities

5.1.3.1.1. Which dependencies were added, removed, or updated.

5.1.3.1.2. Which projects use these components.

5.1.3.1.3. Which Vulnerability data are for these dependencies.

5.1.3.2. Allows you to shift left

5.1.3.3. Needs Github actions to be enabled but actions not needed for dep graph, bot, sec updates, version updates

5.1.3.3.1. Dependency submissin action

5.1.3.3.2. Dependency review action

5.1.3.4. How to setup

5.1.3.4.1. Actions tab > Search and configure Dependency Review > Commit the default dependency-review.yml file in the repository's .github/workflows directory

5.1.3.4.2. Github Marketplace> Actions> dependency-review-action

5.2. GIthub Advisory Database

5.2.1. https://github.com/advisories

5.2.2. Uses CVSS

5.2.3. Dependendabot uses dependency graph in GHAS to cross-reference dependency data with Github Advisory Database

5.2.4. Sources:

5.2.4.1. National vuln DB, G vulncheck DB, friendsofPHP DB etc.

5.2.5. Terminologies

5.2.5.1. advisory

5.2.5.1.1. security vulnerability report that helps developers identify and fix issues in open-source projects

5.2.5.2. Github Security advisories

5.2.5.2.1. platform for managing and sharing information about security vulnerabilities in open source software

5.2.5.2.2. safe space for code maintainers to discuss how to best address errors and vulnerabilities found in the codebase

5.2.5.3. Github security advisory database

5.2.5.3.1. comprehensive repository that includes CVEs (Common Vulnerabilities and Exposures) and GitHub-originated security advisories

5.3. Software Bill of Materials (SBOM)

5.3.1. formal, machine-readable inventory of a project's dependencies and associated information (such as versions, package identifiers, and licenses)

5.3.2. Export current state of your dep graph as an SBOM using SPDX format via

5.3.2.1. Github UI

5.3.2.2. REST API

5.3.3. Leverage SBOM for auditing and regulatory compliance and legal requirements

5.3.4. Help reduce supply chain risks by:

5.3.4.1. Providing transparency about the dependencies used by your repository.

5.3.4.2. Allowing vulnerabilities to be identified early in the process.

5.3.4.3. Providing insights into the license compliance, security, or quality issues that may exist in your codebase.

5.3.4.4. Enabling you to better comply with various data protection standards.

6. CodeQL

6.1. Code scanning with github codeQL

6.1.1. Notes

6.1.1.1. Without using GitHub code scanning with CodeQL, it would be difficult to automate both the scanning of your code, and generating pull requests to fix the vulnerable code. In addition, CodeQL provides an extensive, growing library of queries in multiple languages that help you create more secure code with little engineering effort.

6.1.1.2. If a repo is forked, before you enable code scanning, enable Github Actions first for code scanning to be available

6.1.1.3. CodeQL treats code like data, allowing you to find potential vulnerabilities in your code with greater confidence than traditional static analyzers.

6.1.1.3.1. Differences between QL and general purpose prog languages

6.1.1.4. Code scanning features of public vs private repos table in stick notes

6.1.1.5. The show paths experience in GitHub's CodeQL analysis provides insight into the execution path that data takes through the code, potentially leading to a security vulnerability. This feature allows developers to understand how untrusted data can flow through the application to a vulnerable point, offering valuable context for understanding and mitigating reported security issues. It is a critical tool for diagnosing complex vulnerabilities that involve data flow across different parts of the codebase.

6.1.1.5.1. show paths

6.1.1.6. When a CodeQL analysis GitHub Actions workflow detects a new vulnerability on a pull request, where can you find the information about that vulnerability?

6.1.1.6.1. Directly in the pull request in the form of a PR comment and a check failure

6.1.1.7. How can you configure your GitHub repository to run CodeQL analysis on a schedule?

6.1.1.7.1. By using the default CodeQL analysis setup

6.1.1.7.2. By creating a GitHub Actions workflow with a schedule trigger. The workflow should leverage actions from the github/codeql-action repository

6.1.1.8. Retrieve detected vulnerabilities programmatically using

6.1.1.8.1. Github GraphQL

6.1.1.9. CLI's built-in search operations

6.1.1.9.1. automatically look in all the sibling directories for the files used in database creation and analysi

6.1.2. Terminologies

6.1.2.1. CodeQL

6.1.2.1.1. https://codeql.github.com/

6.1.2.1.2. Analysis engine used by

6.1.2.1.3. code - treated as data

6.1.2.1.4. sec vulns, bugs, errors - treated as queries

6.1.2.1.5. Supported languages - compiled+interpreted languages

6.1.2.2. Variant analysis

6.1.2.2.1. using a known security vulnerability as a seed to find similar problems in your code

6.1.2.2.2. codeQL queries used for variant analysis

6.1.2.3. CodeQL Databases

6.1.2.3.1. contain queryable data extracted from a codebase, for a single language at a particular point in time

6.1.2.3.2. full, hierarchical representation of the code

6.1.2.3.3. DB contains all necessary data to run queries on the code

6.1.2.4. Query Suites

6.1.2.4.1. default

6.1.2.4.2. security-extended

6.1.2.5. CodeQL packs

6.1.2.5.1. types

6.1.2.5.2. CodeQL packs are used to create, share, depend on and run codeql queries and libraries

6.1.2.5.3. contain

6.1.2.6. QL

6.1.2.6.1. Query

6.1.2.6.2. Declarative, object-oriented query language

6.1.2.6.3. Properties of a good QL

6.1.2.6.4. QL Syntax

6.1.3. How CodeQL scans or analyzes code? - 3 steps

6.1.3.1. Preparing the code, by creating a CodeQL database.

6.1.3.1.1. Start Extraction → CodeQL extracts a single relational representation of each source file.

6.1.3.1.2. Data Compilation after Extraction

6.1.3.2. Running queries from CodeQL repo/custom queries against the database created USING

6.1.3.2.1. CodeQL CLI

6.1.3.2.2. VS code codeQL extension

6.1.3.3. Interpreting the query results.

6.1.3.3.1. Results from query execution are interpreted into a more meaningful way by using query's metadata properties

6.1.3.3.2. Queries that don’t have metadata are not interpreted; their results are output as a table and not displayed in the source code

6.2. Identify security vulnerabilities in your codebase using cdeQL

6.2.1. Install CodeQL CLI

6.2.1.1. use the CodeQL CLI standalone product to analyze code and to generate a database representation of a codebase

6.2.1.2. Download codeQL CLI bundle (CLI+queries) zip package on githubs site

6.2.1.3. codeql-bundle.tar.gz

6.2.1.3.1. CLI for all supported platforms

6.2.2. Prepare a DB using CodeQL CLI

6.2.2.1. DB created using extraction and compilation

6.2.2.2. Extractors

6.2.2.2.1. Each langugage extractor defines its own set of configuration options.

6.2.2.2.2. E.g.: Entering codeql resolve extractor --format=betterjson results in data formatted

6.2.2.3. Create a CodeQL database by running this command from the checkout root of your project

6.2.2.3.1. codeql database create <new DB path> --language = <language - identifier for DB creation>

6.2.2.4. Potential shortfalls of DB creation

6.2.2.4.1. Using autobuild

6.2.3. Run codeQL querirs on this DB to find code vulns

6.2.3.1. CodeQL queries

6.2.3.1.1. Types

6.2.3.1.2. Structure

6.2.3.2. Results obtained in SARIF format

6.2.4. Analyze CodeQL scan results using GitHub created queries or custom queries

6.2.5. Uplaod results to Github

6.2.6. Understand CodeQL results

6.2.6.1. View codeQL analysis results

6.2.6.1.1. Results from CodeQL scans appear directly in your source code (VS Code extension) or in CLI-generated reports.

6.2.6.1.2. Modify your query’s **select** statement to make results more understandable.

6.2.6.1.3. Write your own queries in the query console or in the CodeQL extension for VS Code

6.2.6.1.4. For GitHub alerts, ensure results are in the right format.

6.2.6.2. Code Scanning Alerts

6.2.6.2.1. **Alerts ** seen in Security> Vulnerability alerts> Code scanning. Alerts in security tab closed after fixing a vuln

6.2.7. Troubleshoot CodeQL results

6.2.7.1. Optimize CodeQL analysis runtimes

6.2.7.1.1. Self hosted runners for CodeQL analysis increase memory or number of cores

6.2.7.1.2. Use matrix while scanning multiple languages to run in parallel

6.2.7.1.3. Code analysis time proportional to amount of code -- Try breaking code into multiple workflows/subsets

6.2.7.1.4. You might want to trigger analysis on the schedule event only if your analysis is too slow during push or pull_request events.

6.2.7.2. Optimize codeQL queries

6.2.7.2.1. CodeQL predicates and classes are evaluated to database tables. Large predicates generate large tables with many rows, so they're expensive to compute.

6.2.7.2.2. The QL language is implemented through standard database operations and relational algebra, such as join, projection, and union.

6.2.7.2.3. Queries are evaluated bottom up, which means that a predicate is not evaluated until all of the predicates that it depends on are evaluated.

6.2.7.3. Debug Artifacts

6.2.7.3.1. Enable Debug Mode: Modify the init step in the CodeQL workflow file and set debug: true.

6.2.7.3.2. Automatic Artifact Upload: Debug artifacts are automatically uploaded to the workflow run.

6.2.7.3.3. Artifact Name: The uploaded debug data is named debug-artifacts.

6.2.7.3.4. Contents of Debug Artifacts: Includes CodeQL logs, databases, and SARIF files to help diagnose issues.

6.2.7.4. CodeQL extension for VS code with log files

6.2.7.4.1. CodeQL Extension Log

6.2.7.4.2. common error messages

7. Code Scanning

7.1. Achieved using

7.1.1. CodeQL

7.1.1.1. Github's code analysis engine to automate security checks

7.1.1.1.1. Code Scanning Setup options using Github CodeQL

7.1.2. Third Party CI Tools

7.1.2.1. Setup options

7.1.2.1.1. Use Github Actions

7.1.2.1.2. Upload **SARIF ** (Static Analysis Results Interchange Format) v2.1.0 files generated as part of external CI setup/outside Github/outside your repo using

7.2. Available for and Billing

7.2.1. Free for public repos and self hosted runners

7.2.2. Code scanning is typically implemented using GitHub Actions workflows, so the scans consume GitHub Actions minutes on both public and private repos

7.2.2.1. more frequently scans are performed or the more complex they are, the greater the consumption of GitHub Actions minutes.

7.2.2.2. optimize workflows to manage quota usage effectively.

7.2.3. GitHub does not specifically sponsor GitHub Actions minutes for code scanning beyond what is already offered for public repositories and subscription plans.

7.2.3.1. Public repositories have free GitHub Actions minutes sponsored by GitHub, including those consumed by code scanning.

7.2.3.2. Private repositories consume GitHub Actions minutes for code scanning, impacting the user's quota.

7.2.4. orgnzn private repos with GHAS license with Github Code Security enabled

7.2.4.1. Code scanning uses GitHub Actions, and each run of a code scanning workflow consumes minutes for GitHub Actions as actions run on runners

7.2.4.2. Limited number of free minutes and storage for GitHub Actions, including code scanning. If you exceed this limit, additional usage is billed based on your plan. Monthly-billed accounts have a default $0 spending limit, preventing extra charges, while invoice-billed accounts have unlimited usage by default. Minutes reset monthly, but storage usage does not

8. API Endpoints

8.1. Code Scanning

8.1.1. GET /orgs/{org}/code-scanning/alerts

8.1.2. GET /repos/{owner}/{repo}/code-scanning/alerts

8.1.3. GET /repos/{owner}/{repo}/code-scanning/alerts/{alert_number}

8.1.4. /repos/{owner}/{repo}/code-scanning/analyses/{analysis_id}

8.1.5. Has PATCH and POST

8.2. Dependabot

8.2.1. GET /enterprises/{enterprise}/dependabot/alerts

8.2.2. GET /orgs/{org}/dependabot/alerts

8.2.3. GET /repos/{owner}/{repo}/dependabot/alerts

8.2.4. PATCH /repos/{owner}/{repo}/dependabot/alerts/{alert_number}

8.2.5. No POST

8.3. Secret Scanning

8.3.1. GET /enterprises/{enterprise}/secret-scanning/alerts

8.3.2. GET /orgs/{org}/secret-scanning/alerts

8.3.3. GET /repos/{owner}/{repo}/secret-scanning/push-protection-bypasses

8.3.4. GET /repos/{owner}/{repo}/secret-scanning/alerts

8.3.5. Has PATCH and POST