遵循以下最佳实践的项目将能够自愿的自我认证,并显示他们已经实现了核心基础设施计划(OpenSSF)徽章。 显示详细资料
[](https://www.bestpractices.dev/projects/3538)
<a href="https://www.bestpractices.dev/projects/3538"><img src="https://www.bestpractices.dev/projects/3538/badge"></a>
Jenkins automation server
https://github.com/jenkinsci/jenkins/blob/master/CONTRIBUTING.md#proposing-changes
The Jenkins project uses a Contributor License Agreement mechanism which applies to all contributors who get special permissions, including write access to the Jenkins core repository (Jenkins CLA Documentation). There is no legal mechanism applying to all contributions.
https://www.jenkins.io/project/governance/
https://www.jenkins.io/project/conduct/
The project has more than eight people with admin rights to the GitHub repository and multiple maintainers that can create and close issues, accept proposed changes, and release new versions of the software. https://www.jenkins.io/project/team-leads/ https://www.jenkins.io/project/board/
The project has a bus factor of over 2 https://github.com/orgs/jenkinsci/people
Jenkins Developer Documentation includes a section with the Architecture overview and links to the details of key components. There is ongoing migration of the developer documentation from Jenkins Wiki, so some pages might reference the old page locations.
Jenkins Security process is documented here
Jenkins Documentation contains a guided tour for newcomer users: https://www.jenkins.io/doc/pipeline/tour/getting-started/
The project makes an effort to keep documentation up to date and encourages contributors to verify that any pull requests also update documentation for things that are modified. https://github.com/jenkinsci/jenkins/blob/master/.github/PULL_REQUEST_TEMPLATE.md
https://github.com/jenkinsci/jenkins#about
The Jenkins project does not fully meet the WCAG 2.0 criteria at the moment. There is ongoing project in the Jenkins User Experience SIG which would improve accessibility and align it with modern requirements
Jenkins project supports localization of its Web Interface, and there are multiple localization options available. Localization features are available right inside the Jenkins core, and there are also multiple plugins improving localization experienceand additional features. References
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.
后退