Continuous Integration and Continuous Delivery/Deployment (CI/CD) pipelines exist to ship software fast. The increasing rate of vulnerabilities in dependencies and container images, however, means that many products ship with major undetected or unaddressed security problems. Detection often occurs only in the production phase, which comes quickly in today’s high-velocity software development practices.
GitHub Actions is a central part of build-and-test automation in many organizations. With pipelines operating so quickly, security scanning has become a nonnegotiable part of the process, making AppSec tools like JFrog Xray essential to CI/CD workflows.
Source: GeeksforGeeks.com
Security in the Pipeline
Security is most effective when it operates throughout the pipeline. While shift-left practices remain essential for catching issues early in development, they are not sufficient on their own. Vulnerabilities can still emerge or go undetected later in the lifecycle, making continuous scanning within the CI/CD pipeline just as critical.
The JNDI lookup exploit in the Log4Shell feature of Log4j from 2021 is a well-known example of how severe these vulnerabilities can be. Log4j had the capacity to dynamically fetch and even load resources externally. This allowed attackers to fetch binaries from external servers, enabling remote code execution on affected systems.
Notably, attacks like these are increasingly hitting the entire software supply chain. Without pipeline-level scanning, the benefits of continuous delivery can quickly turn into attack vectors. The GitHub Actions Security Guides provide useful direction for hardening these workflows.
How JFrog Xray Fits Into CI/CD
Xray is an integrated component of JFrog Artifactory, where it performs binary-level software composition analysis (SCA) scans on managed artifacts. In practice, Xray applies to the build stage and inspects the full dependency graph rather than just top-level packages. This includes transitive dependencies, container layers, and anything resolved during the build. It also uses CVSS scoring to assess severity and prioritize remediation. The JFrog Security Research Team supplements public vulnerability databases with additional research, helping to surface both known exploits and emerging risks.
Malicious package detection is a distinct feature beyond CVE scanning. Xray does the following:
- Screens millions of OSS packages at the binary level for intentionally malicious behavior
- Incorporates public advisories and proprietary research
- Provides built-in mitigation and remediation guidance
Teams can also use JFrog to identify open source licenses across the dependency tree. If a license conflicts with internal policy, it can be flagged early in the pipeline.
Additionally, Xray performs impact analysis to trace vulnerabilities through dependencies. This helps teams understand which top-level components are affected, so they don't need to chase issues deep in the dependency chain.
Xray also continuously monitors artifacts stored in Artifactory. When new CVEs are disclosed, previously scanned components are re-evaluated automatically, so issues don't go unnoticed after initial deployment.
Setting Up the JFrog-GitHub Actions Integration
CI/CD integration with JFrog Xray starts with a properly configured environment. This typically includes a JFrog instance, either on JFrog Cloud or a self-hosted Artifactory deployment, along with a GitHub repository that has Actions enabled.
As part of the workflow, build information is published to Artifactory, where Xray analyzes it for vulnerabilities and policy violations across the full dependency graph.
Example
The exact setup will vary depending on your build system, but a minimal GitHub Actions workflow might look like this:
name: Security Scan with JFrog Xray
on:
push:
branches: [main]
pull_request:
jobs:
xray-scan:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Setup JFrog CLI
uses: jfrog/setup-jfrog-cli@v4
env:
JF_URL: ${{ secrets.JF_URL }}
JF_ACCESS_TOKEN: ${{ secrets.JF_ACCESS_TOKEN }}
- name: Scan build with Xray
run: |
jf bs ${{ github.workflow }} ${{ github.run_number }}
This workflow uses the JFrog CLI to trigger an Xray scan against the current build context. In a full setup, teams typically publish build info to Artifactory so that Xray can analyze the complete dependency graph, including transitive dependencies resolved during the workflow.
Note that this approach works across most common build ecosystems — npm, Maven, Gradle, Docker, and others — because the scan operates on build metadata rather than any specific package manager.
Configuring Xray Policies and Watch Rules
Policies define what counts as a violation. Teams can create rules based on severity thresholds, license compliance, or specific operational risks. Common policy actions include flagging, warning, or blocking builds.
Watches define the scope of monitoring. These can be applied to repositories, builds, or artifact bundles, depending on how broadly you want to enforce policies.
Many teams begin with an audit mode to surface issues without immediately failing builds. This allows for gradual adoption while still identifying gaps.
This creates security rules that are:
- Versioned
- Reviewable
- Reversible
- Consistent across teams
Source: JFrog Integration Workflow
What Happens When a Violation Is Found
Once policies are enforced, violations can fail builds during the pipeline. This prevents vulnerable components from being merged, promoted, or deployed.
Instead of requiring separate tools, results appear directly in the developer workflow. Teams can view failures alongside test results within GitHub Actions, reducing context switching.
Xray provides detailed output, including:
- CVE identifiers
- CVSS severity scores
- Affected dependencies
- Recommended fix version
- The policy responsible for the violation
Scan results can also be surfaced in GitHub Actions job summaries, with links back to detailed reports in the JFrog platform. This makes it easier for teams to triage and respond quickly. Temporary ignore rules can also be applied where appropriate.
CI/CD Integration Done Right
The integration is relatively lightweight, and most teams can get a basic scan running with the JFrog CLI and a small addition to their workflow. Once in place, policy enforcement becomes automatic, reducing reliance on manual reviews.
As attacks increasingly target the software supply chain, pipeline-level scanning is no longer optional. It's a baseline requirement for DevSecOps. Integrating security into CI/CD workflows early allows teams to spend less time reacting to issues and more time shipping reliable software.
Top comments (0)