Supply Chain Security
This section describes how OpenSSF Scorecards are implemented.
Scorecards provide an automated assessment of repository security, including checks such as:
- Use of branch protection rules and repository rules
- Dependency update practices
- Code review enforcement
- Security policy presence
These results help maintainers track improvements and identify potential gaps in supply chain security.
Scorecards are implemented using CI/CD workflow in major Wren Security repositories. Here is example implementation.
Scorecards run automatically:
- On push to the
mainbranch. - On a weekly schedule for continuous monitoring.
- On branch protection rule, when branch protection rules are changed.
Each repository publishes its Scorecards report to a public dashboard:
- reports can be found at https://securityscorecards.dev/viewer/?uri=github.com/WrenSecurity/<repository name> or searched at https://securityscorecards.dev/viewer/
- example of scorecard report: wrensec-commons Scorecard
This section provides a technical description of how SonarQube analysis is implemented across repositories, how developers interact with it,
and the steps required to enable it for new repositories.
SonarQube provides static code analysis to identify bugs, security vulnerabilities, code duplication, and insufficient test coverage.
Reports are available on SonarCloud, which enables developers to monitor code quality during pull requests and helps monitor and maintain security across repositories and over time.
SonarQube is implemented using CI/CD-based analysis. Repositories call reusable workflows located in .github/.github/workflows.
Reference implementation:
The wrensec-commons repository demonstrates the standard setup with these workflows:
build-project.ymlsonar-trigger.yml
Analyses are triggered by:
- Opening a new pull request
- Force-pushing to an existing pull request
- Merging a pull request into the
mainbranch
- Create a project in SonarCloud for the repository.
-
Obtain required credentials:
- Sonar Token – used in the CI/CD pipeline for authentication and sending analysis results.
- Project Key – unique identifier of the repository in SonarCloud.
-
Configure GitHub Actions:
- Add workflow YAML files that reference the reusable workflows.
- Provide the correct project key in configuration.
- Store the Sonar token in the repository’s GitHub Secrets.
- Once configured, every pull request and every push to the
mainbranch will trigger a SonarCloud analysis.
When a pull request is submitted, SonarCloud analysis runs automatically. After successful analysis, developers receive a SonarCloud bot comment directly on the pull request. The comment contains metrics relevant to the changes in that pull request, including:
- Code coverage of new tests
- Code duplication rate
- Potential security vulnerabilities
The comment also provides a link to the full SonarCloud report for that pull request.
All project analyses are publicly available at:
SonarCloud – Wren Security Projects.
This section describes the CodeQL configuration used across repositories.
CodeQL detects potential security vulnerabilities (e.g., insecure API usage, injection risks, unsafe coding patterns).
Findings are primarily used by the security team for ongoing monitoring and improvement.
- Integration: Default GitHub CodeQL setup.
- Scope: Enabled on all repositories in the organization.
CodeQL runs automatically:
- On push and pull requests to
mainand other protected branches. - On a weekly schedule.
- Results are collected under each repository’s Security > Code scanning alerts.
- Access to CodeQL alerts is limited to selected organization members.
- Developers contributing code do not need to configure anything; the analysis runs automatically.
Unless otherwise noted, all content is © 2018 Wren Security, and licensed under the Creative Commons BY License.
