Safeguard
Security Guides•

Is Jenkins Configuration as Code safer than clicking in the UI?

Jenkins Configuration as Code puts controller settings in reviewed YAML. Where it helps, where secrets can leak, and how to adopt it on an old controller.

Safeguard Security Team
3 min read

Jenkins Configuration as Code can be safer than UI edits because settings live in YAML you can review, version and roll back. It does not make a controller secure by itself. You still have to keep secrets out of the file and decide who may change it.

What it is

The Configuration as Code plugin, often called JCasC, defines a controller's configuration in a human readable YAML file. You can store it in source control, track changes and roll back. The default file has four top level sections: jenkins, tool, unclassified and credentials.

Security benefits

  • Review. A change to security settings becomes a pull request instead of a click nobody saw.
  • Drift control. The file is the source of truth. UI edits are overwritten at the next restart, so surprise changes do not last.
  • Rebuilds. You can recreate a controller from the file, which helps recovery and migration.
  • Audit. Git history answers who changed the authorization matrix and when.

Cautions

  • Secrets. The export includes a credentials section. The documentation says you may want to delete it. Do not commit plaintext secrets, and use the plugin's secret handling options instead of literal values.
  • Mixed sources. Pick JCasC or the UI. Editing in both leads to confusion.
  • Conflicts. If multiple files set the same value, JCasC raises a ConfiguratorException.
  • YAML traps. The file is case sensitive, indentation matters, only spaces are allowed, and unquoted values like Yes or 2 become Boolean or numeric.
  • Read access. The export shows settings. The Extended Read Permission plugin can grant read only access to configuration without full admin.

Adopting it on a legacy controller

  1. Open Manage Jenkins, then Configuration as Code, then View Configuration.
  2. Download the YAML and commit the unmodified default to source control first.
  3. Remove or externalize the credentials section.
  4. Edit the file in a branch with review.
  5. Test on a staging controller, using Reload existing configuration. A restart is not required, though one helps test substantive changes.
  6. Point production at the file with the CASC_JENKINS_CONFIG variable or the casc.jenkins.config property. The default location is $JENKINS_HOME/jenkins.yaml, and the value can be a folder, file or URL.

Try it yourself

The demo shows mapping controls to a framework, the same idea as tying a config change to a documented control.

Click through it at your own pace, or open it full screen.

Where Safeguard fits

Safeguard automates compliance evidence and enforces policies, which can complement reviewed configuration. Try the free scan.

Quick check

Do UI changes survive a restart with JCasC?

No. UI edits still work, but they are overwritten at the next controller restart.

Should the credentials section be committed?

Review it first. The docs note you may want to delete it, and plaintext secrets should never be committed.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.