jenkins

The Jenkins project has an LTS release strategy documented here https://www.jenkins.io/download/lts/. All prior releases are available via Jenkins' artifactory. Upgrade guides are published for every release, if needed.

Jenkins Issue Tracker: https://issues.jenkins.io/ . Project = JENKINS, component = core , query . Some sub-components like Docker packaging also use GitHub Issues as a second way to report issues: https://github.com/jenkinsci/docker/issues

All recent Jenkins security advisories (since 2017) give credit to the reporter(s) of vulnerabilities in the Jenkins core, infrastructure and plugins.

The project documents the process for responding to vulnerability reports: https://www.jenkins.io/security/reporting/

The project encourages contributors to follow its coding style guidelines outlined on the project website https://www.jenkins.io/doc/developer/publishing/style-guides/

The project automatically enforces its coding style guidelines via the Apache Maven Checkstyle Plugin, the maven spotbugs plugin, the maven spotless plugin, ESLint and Stylelint.

No native binaries are being generated by the project.

The standard Java and Maven build and installation system can be freely configured by users as they wish. The project does not restrict the user of relevant flags.

The project does not recursively build subdirectories. All of its dependencies are external to its installation.

No true building occurs since the project uses Maven.

Docker

Jenkins releases produce different artifacts for different operating systems and architectures.

The project's contribution guidelines explain how to install the project quickly, its dependencies, how to set up an environment and run tests: https://github.com/jenkinsci/jenkins/blob/master/CONTRIBUTING.md#building-and-debugging

The project monitors dependency updates using GitHub native dependabot: https://github.com/dependabot and renovate: https://github.com/renovatebot/renovate

The project monitors dependency updates using GitHub native dependabot and automatically performs updates when they become available.

The project monitors dependency updates using GitHub native dependabot and automatically performs updates when they become available. Deprecated dependencies are routinely replaced.

The project uses Jenkins to run the automated test suite on each pull request and push to a branch: https://github.com/jenkinsci/jenkins/blob/master/Jenkinsfile

The project maintains a dedicated acceptance test (https://github.com/jenkinsci/acceptance-test-harness) and plugin compatibility (https://github.com/jenkinsci/plugin-compat-tester) suite to add tests to if regressions are fixed.

The project's pull request template contains a dedicated point to ensure new functionality added is covered by tests: https://github.com/jenkinsci/jenkins/blob/master/.github/PULL_REQUEST_TEMPLATE.md

It is a part of our Pull Request Template requirements

Jenkins uses high and medium thresholds for static analysis warnings. ([JENKINS-36716])(https://issues.jenkins.io/browse/JENKINS-36716) intends to implement and maintain higher code quality standards. The Jenkins project does not accept pull requests with Spotless, Spotbugs, Checkstyle, ESLint or Stylelint warnings.

The project strives to implement secure design principles.

Jenkins core generally does not rely on SHA-1 for security purposes. The only security-related use of SHA-1 in the Jenkins core is related to the validation of downloaded plugins and Jenkins .war files from update sites. This is only used as a fallback if the update site does not provide SHA-256 or SHA-512 checksums, and a warning is logged. Official Jenkins update sites have provided these better checksums since April 2018, so this only matters for third-party unofficial update sites, and only if downloads are not delivered via HTTPS.

CBC mode is not used by the Jenkins core, and the algorithm is removed from the SSHD Module which implements the SSH server side logic in Jenkins.

Note: In some cases we use AES encryption with default settings provided by JVM, without explicit padding and mode specification. This results in ECB usage in some circumstances in the case of the default JVM configuration. ECB is not optimal due to data correlation analysis weakness, but it is not considered as a serious weakness for short data objects. Jenkins users have an option to change the JVM defaults to enforce strong cryptography and other default AES modes.

The project supports multiple cryptographic algorithms, where applicable.

The project supports the storage of private cryptographic keys and dynamic tokens.

The project supports TLS for all of its network communications.

The project supports at TLS version 1.2, as provided by this property: -Dhttps.protocols=TLSv1.2

The project performs TLS certificate verification by default.

The project performs certificate verification, and before sending HTTP headers.

The project documents the process for obtaining public signing keys and verifying releases of the project: https://www.jenkins.io/download/verify/

Jenkins project is being regularly scanned by various static analysis tools, including tools like Snyk or Anchore. GitHub Security is also used for dependency scanning and reporting. Also, Jenkins users regularly run static code analysis tools against the codebase/distributions and then report the results. In addition to that, there is ongoing discussion about including FindSecBugs detectors into standard Pipelines.

Jenkins project does not include code written using a memory-unsafe language. We use some 3rd-party dependencies which include native code, e.g. Windows Process Management Library written in C. This library is provided by a third party, and it is not in the scope for this certification.