GitHub does not ship a default SCA tool the way GitLab does. You have to combine two things: a platform feature called Dependabot and an SCA action from the Marketplace. In Part 3 of the GitHub DevSecOps series, Patrick Steger and I wire both into our pipeline — and find out the hard way that the Marketplace path is not as smooth as the slides suggest.
What SCA Is and Why You Need Both Approaches#
Software Composition Analysis — also called dependency scanning — finds known vulnerabilities in the libraries your application uses. If a library has a CVE and you depend on it, your application carries that CVE. New CVEs against existing libraries get discovered all the time, so a one-shot scan is not enough. You need scans on every commit and scans on a schedule against unchanged code.
On GitHub that means two complementary tools. A pipeline-side SCA action gives you scan-on-commit under your direct control. A platform feature called Dependabot gives you continuous scanning, alerts, and auto-generated fix pull requests independent of your commits. The combination usually finds things either tool misses on its own.
Enabling Dependabot#
Dependabot is a GitHub feature, not a workflow. You enable it under Settings → Code security and analysis. First switch on the dependency graph — that is what builds the inventory of your dependencies. Then enable Dependabot alerts (so GitHub tells you when a new CVE matches one of your dependencies) and Dependabot security updates (so it opens pull requests with the upgrade already prepared).
There is a third option, Dependabot version updates, which opens PRs for any new minor version regardless of CVE. We left it off — every minor upgrade as a PR turns into noise quickly.
Once enabled, Dependabot scans the repo in the background. Insights → Dependency graph shows you the inventory: our pom.xml lit up with maven-surefire, Spring Boot, and — pleasingly — even the GitHub Actions our workflows depend on. The Security tab is where Dependabot alerts appear if they exist.
Adding an SCA Action to the Pipeline#
There is no first-party GitHub SCA action, so we go to the Marketplace and pick CRDA — CodeReady Dependency Analysis from Red Hat, which uses Snyk under the hood. We also need to enable GitHub Advanced Security under Settings → Code security and analysis (this is paid for private repos) so the scan results show up in the Security tab.
We add an sca step to the main pipeline that calls a separate sca.yml workflow and inherits secrets. The SCA workflow needs the build to finish first because it scans the resolved dependencies, so we declare a needs: build dependency.
The sca.yml workflow itself sets fail-fast: false because we want the full set of findings, not just the first one. It runs on a matrix of operating systems, checks out the repo, installs Java, installs the CRDA tool, runs redhat-actions/crda@v1.2, and uploads the standard SARIF findings file so GitHub can render it.
CRDA needs two secrets: a SNYK_KEY (you create a free Snyk account at app.snyk.io and copy the API key from your account settings) and a GitHub token for the OpenShift Tools installer (the default GITHUB_TOKEN works). Both go under Settings → Secrets → Actions.
What Actually Happened#
The first run worked. The pipeline built, the SCA job ran, CRDA scanned, vulnerabilities showed up under Security → Code scanning sorted by tool, severity, branch, and rule. Real findings against the deliberately outdated Spring Boot version we had pinned.
Then we tried to re-run the pipeline an hour later and things fell apart. CRDA returned connection timeouts. The Snyk key worked for two or three scans and then refused to authenticate. Patrick was blunt about it: as it stands, this is not enterprise ready. Worth knowing if you are evaluating CRDA for production use.
One small thing also surprised us: the severity labels in the GitHub UI are “error / warning / note” instead of the “critical / high / medium / low” we are used to from the security world. Not wrong, just different — adjust your triage scripts accordingly.
Dependabot vs the Pipeline Scan#
Curiously, after waiting some time, Dependabot still reported no alerts on the same repository where CRDA found real vulnerabilities. We never fully figured out why. The lesson is that neither tool is a complete answer on its own — Dependabot for the always-on platform view, a pipeline SCA tool for scan-on-commit, and a real evaluation of which third-party tool you actually trust for the latter.
Key Takeaways#
GitHub has no default SCA tool. You build the SCA capability yourself by combining Dependabot (platform) with a Marketplace action.
Enable Dependabot first. Dependency graph, alerts, and security updates take three toggles in settings. Skip version updates unless you want a PR for every minor bump.
The Marketplace SCA path is rough. CRDA + Snyk works in demos but proved unreliable under load. Connection timeouts and short-lived API keys made it unusable for enterprise.
Pipeline SCA needs
needs: build. The scan runs against resolved dependencies, so the build job has to complete first. Use a separate workflow file called from main, with secrets inherited.Severity labels are different. GitHub shows “error / warning / note” in code scanning, not the “critical / high / medium / low” you are used to. Adjust your triage accordingly.
Evaluate the SCA tool seriously before committing. The one shown in the video is not the answer. Pick a tool with a track record, account-grade API limits, and a reliable scanner — and verify it under real load before you wire it into every pipeline.