Boost Jenkins pipelines with Red Hat Advanced Developer Suite

Jenkins has powered countless CI/CD pipelines for more than a decade, but that popularity comes at a cost: the more your teams automate, the harder it gets to keep every job file, plug-in, and artifact secure and up to date. Builds grow, pipelines sprawl, and before long you’re maintaining your DevOps toolset as much as you’re building software. Worse yet, every shortcut you take to move faster can become an open door for attackers. Does this sound familiar?

That’s where the Red Hat Advanced Developer Suite comes in. Combining an internal developer portal like Red Hat Developer Hub with security tools such as Red Hat Trusted Artifact Signer and Red Hat Trusted Profile Analyzer can turn a CI tool like Jenkins from "just a build server" into a streamlined, policy-aware delivery engine. The result: faster feedback loops for developers and higher confidence for the security team.

If your goal is to build faster while shipping better, read on as we turn a stock Jenkins instance into a resilient pipeline you can trust in production.

Meet Red Hat Advanced Developer Suite

In today’s zero-trust, open source world, raw speed isn’t enough—every artifact must prove it’s safe before it ever touches production. Red Hat Advanced Developer Suite bakes that assurance straight into the developer workflow, pairing high-octane productivity with end-to-end supply-chain security. Together, they deliver the sweet spot DevOps teams crave: move fast with one-click environments, yet ship confidently knowing the entire supply chain is continuously validated, signed, and enforceable in production.

The following Advanced Developer Suite components help accelerate innovation with enterprise-grade security in mind:

Preview: The bulletproof Jenkins pipeline we'll build in this series

Figure 1 shows the end-to-end CI/CD flow we’ll assemble throughout the course of this two-part series. Every green diamond is a security guardrail that fires automatically. We have introduced two tools to complement the Red Hat Advanced Developer Suite stack:

• Red Hat Quay: An image registry that extends that trust to the storage tier, adding enterprise-grade scanning and secure content distribution.
• Red Hat Advanced Cluster Security for Kubernetes: Closes the loop at runtime, blocking anything that slips through or has been tampered with after the fact.

Picture the flow from code to production (Figure 1) as a relay race where every baton hand-off is double-checked for tampering:

1. Code commit: The moment a change leaves a laptop, Red Hat Trusted Artifact Signer stamps it with a cryptographic signature.
2. Verify commit: If the signature isn’t there (or doesn’t match the author), the build never starts.
3. Sign image: Jenkins pulls the repo and compiles as usual, then the pipeline assembles a container image and immediately reinvokes the Red Hat Trusted Artifact Signer to attach a provenance record and image signature. From here on, the image’s identity is provable.
4. Generate an SBOM: Red Hat Trusted Artifact Signer generates an SBOM, which is passed to Red Hat Trusted Profile Analyze to scan every dependency for CVEs, license issues, or policy violations.
5. Push to registry: Clean images are stored in Red Hat Quay along with the image signature and attestation. Quay’s built-in scanner kicks in, adding another layer of malware and vulnerability detection while the artifact is at rest.
6. Image scanning: Red Hat Advanced Cluster Security performs a deeper inspection of the image. It adds an extra layer of scrutiny, zeroing in on runtime vulnerabilities and supply-chain red flags.
7. Policy enforcement: When the CD stage requests the image, Red Hat Advanced Cluster Security acts as an admission controller. It makes sure the image is compliant with all the organization’s policies before allowing it to be deployed.
8. SLSA compliance: Red Hat Trusted Artifact Signer uses Conforma to check the image is SLSA compliant, and only then allows the deployment onto Red Hat OpenShift.

This series tackles the two pillars of Red Hat Advanced Developer Suite: velocity and security. In this post, we’ll show how Advanced Developer Suite lets developers innovate at speed. In a follow-up post, we’ll embed guardrails that help secure the software-supply chain—without slowing anyone down.

Now that you’ve seen the destination, let’s rewind to day one and watch how a new developer experiences that pipeline in practice.

Setting the scene

Every modern DevOps journey begins with a lone developer eager to ship code—only to collide with a mountain of tickets and tool sprawl that stops them in their tracks.

Meet Eddie (Figure 2). It’s his first week on the job, but instead of writing the next great feature, he’s:

• Hunting for docs: "Which Confluence is the real Confluence?"
• Guess-installing CLIs: "Is it GitHub Actions here? Jenkins? Something else?"
• Waiting on access to a dev environment that might—or might not—meet company standards.

Sound familiar? We’ve all been Eddie.

Enter Red Hat Developer Hub

Red Hat Developer Hub is an internal developer portal (IDP)—a self-service platform that pulls your docs, services, and tooling into a single, developer-friendly interface.

Imagine if developers like Eddie had a portal built just for them—a single pane of glass where they could search a central service catalogue, see every component in the organization, and know exactly how to consume or contribute to each one.

With Red Hat Developer Hub, requesting an environment is no longer a ticket-chasing marathon. Eddie fills out 1 form, clicks Create, and the platform does the rest:

• Autogenerates the Git repository
• Provisions the workspace
• Wires in the CI/CD pipeline
• Preconfigures the GitOps workflow
• Includes the latest documentation
• Triggers the deployment to the desired target environment

That seamless experience is powered by Software Templates—golden-path blueprints that codify and automate everything needed to develop, test, and deploy great applications. Let’s peek under the hood of those templates next.

A closer look at Software Templates

A Software Template in Red Hat Developer Hub is a codified set of best practices that guides developers along a proven, low-friction route from idea to production. Think of it as the platform team’s collective wisdom, distilled into a reusable blueprint. They offer:

• Streamlined process: A predefined path removes guesswork and eliminates the dreaded ticket ping-pong.
• Faster onboarding and setup: New services (and even new hires) spin up in minutes, not days.
• Built-in best practices: Naming conventions, folder layout, pipeline wiring, and doc scaffolding are baked in, so every project starts from the same hardened foundation.

Here is a look at a part of a Software Template:

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: quarkus-stssc-jenkins-template
  title: Securing a Quarkus Service Software Supply Chain (Jenkins)
  description: Create a Quarkus Service built with Red Hat Trusted Application Pipeline on Jenkins
  tags:
    - recommended
    - java
    - quarkus
    - maven
spec:
  owner: rhdh
  type: service
  parameters:
    - title: Provide Information for Application
      ...
    - title: Provide Image Registry Information
      ...
    - title: Application repository Information
      ...
  steps:
    - id: template
      name: Fetch Skeleton + Template
      ...
    - id: publish
      name: Publish
      ...
    - id: register
      name: Register
      ...
    - id: template-gitops-deployment
      name: Generating Deployment Resources
      ...
    - id: publish-gitops
      name: Publishing to Resource Repository
      ...
    - id: create-argocd-resources
      name: Create ArgoCD Resources
      ...
  output:
    links:
      - title: Source Code Repository
      ...
      - title: Open Component in catalog
      ...      

Software Template building blocks

Software Templates consist of a few different components:

• Parameters: The handful of details a developer supplies up front when filling the form: service name, owning team, target namespace.
• Actions: Reusable operations such as "fetch skeleton code," "create Git repository," or "deploy Helm chart."
• Steps: An ordered list of those actions, stitched together into a workflow (e.g., pull skeleton → publish to Git → deploy pipeline).
• Outputs: The artifacts and links Red Hat Developer Hub returns when the template finishes: Git URL, build dashboard, live route for quick testing.

What does that look like in practice? The same Software Template that generates Eddie’s repo also drops in a fully-formed Jenkins pipeline. From his very first push, Jenkins launches a pipeline that:

1. Builds the service with Maven.
2. Runs unit tests in a dedicated test stage.
3. Packages and pushes a container image to Red Hat Quay.
4. Autodeploys the build to the QA environment for testing.

Eddie doesn’t write a single line of Groovy, yet he walks away with a production-ready pipeline that matches the organization’s standards. And because the template is CI-agnostic, you could swap Jenkins for Azure DevOps, GitHub Actions, or any other CI tool, and the developer experience would remain just as seamless.

Once the template is in play, Eddie’s ramp-up time vanishes. He’s free to dive straight into the code. Every tool he needs is right at his fingertips, and the underlying infrastructure fades into the background. With automation and standardization baked in, Eddie—and every developer after him—hits "time-to-value" almost immediately.

Feeling confident, Eddie merges his change and hands the new service over to QA. Everything should be smooth sailing—but during testing, something unexpected happens.

When velocity meets vulnerability

Eddie ships his feature and hands the freshly deployed service to QA. Within minutes, the QA engineer fires up their test suite—only to be greeted by a ransomware splash screen instead of the expected API response. The culprit? A compromised open source package that slipped through an unprotected build pipeline.

This is the double-edged sword of modern DevOps: the faster we innovate, the wider the attack surface becomes unless strong security guardrails keep pace. Eddie’s express lane to production showed what’s possible when workflows are automated and standardized—but the incident makes one thing clear: speed without trust is a gamble no team can afford. 

Stay tuned for part 2 of this series, where we'll discover how to address this challenge.

Learn more about Red Hat Advanced Developer Suite.