jenkins

Projekte, die den nachfolgenden Best Practices folgen, können sich freiwillig selbst zertifizieren und zeigen, dass sie einen Core-Infrastruktur-Initiative (CII) Badge erhalten haben.

Es gibt keine Auswahl an Praktiken, die garantieren können, dass Software niemals Fehler oder Schwachstellen hat. Selbst formale Methoden können fehlschlagen, wenn die Spezifikationen oder Annahmen falsch sind. Auch gibt es keine Auswahl an Praktiken, die garantieren können, dass ein Projekt eine gesunde und gut funktionierende Entwicklungsgemeinschaft erhalten wird. Allerdings können Best Practices dabei helfen, die Ergebnisse von Projekten zu verbessern. Zum Beispiel ermöglichen einige Praktiken die Mehrpersonen-Überprüfung vor der Freigabe, die sowohl helfen können ansonsten schwer zu findende technische Schwachstellen zu finden und gleichzeitig dazu beitragen Vertrauen und den Wunsch nach wiederholter Zusammenarbeit zwischen Entwicklern verschiedener Unternehmen zu schaffen. Um ein Badge zu verdienen, müssen alle MÜSSEN und MÜSSEN NICHT Kriterien erfüllt sein, alle SOLLTEN Kriterien müssen erfüllt sein oder eine Rechtfertigung enthalten, und alle EMPFHOLEN Kriterien müssen erfüllt sein oder nicht (wir wollen sie zumindest berücksichtigt wissen). Wenn lediglich ein allgemeiner Kommentar angebeben werden soll, keine direkte Begründung, dann ist das erlaubt wenn der Text mit "#" beginnt. Feedback ist willkommen auf derGitHub-Website als Issue oder Pull-Request. Es gibt auch eine E-Mail-Liste für allgemeine Diskussionen

Wir stellen Ihnen gerne die Informationen in mehreren Sprachen zur Verfügung, allerdings ist die Englische Version maßgeblich, insbesondere wenn es Konflikte oder Inkonsistenzen zwischen den Übersetzungen gibt.
Wenn dies Ihr Projekt ist, zeigen Sie bitte Ihren Badge-Status auf Ihrer Projektseite! Der Badge-Status sieht so aus: Badgelevel für Projekt 3538 ist passing Hier ist, wie man es einbetten:
Sie können Ihren Badgestatus anzeigen, indem Sie folgendes in Ihre Markdown-Datei einbetten:
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/3538/badge)](https://bestpractices.coreinfrastructure.org/projects/3538)
oder indem Sie folgendes in Ihr HTML einbetten:
<a href="https://bestpractices.coreinfrastructure.org/projects/3538"><img src="https://bestpractices.coreinfrastructure.org/projects/3538/badge"></a>


Dies sind die Kriterien das Level Passing. Sie können auch die Kriterien für die Level Silber oder Gold sehen.



 Grundlagen 12/12

  • Identifizierung

    Hinweis: Andere Projekte können den selben Namen benutzen.

    Jenkins automation server

    Welche Programmiersprache wird verwendet, um das Projekt umzusetzen?
    Wenn es mehr als eine Programmiersprache gibt, liste sie als kommagetrennte Werte (Leerzeichen sind optional) auf und sortiere sie von am häufigsten zum am wenigsten verwendeten. Wenn es eine lange Liste gibt, bitte mindestens die ersten drei häufigsten auflisten. Wenn es keine Programmiersprache gibt (z.B. ist dies nur ein Dokumentations- oder Testprojekt), verwenden Sie das einzelne Zeichen "-". Bitte verwenden Sie eine herkömmliche Großschreibung für jede Sprache, z.B. "JavaScript".
    Das Common Platform Enumeration (CPE) ist ein strukturiertes Namensschema für IT Systeme, Software und Pakete. Es wird in diversen Systemen und Datenbanken bei der Meldung von Schwachstellen verwendet.
  • Grundlegende Informationen auf der Projektwebseite


    Genug für ein Badge!

    Die Projekt-Website MUSS prägnant beschreiben, was die Software tut (welches Problem löst sie?). [description_good]
    Dies MUSS in der Sprache sein, die potenzielle Nutzer verstehen können (z.B. möglichst wenig Fachbegriffe verwenden).

    Main use-cases are documented on the jenkins.io landing page



    Genug für ein Badge!

    Die Projekt-Website MUSS Informationen darüber enthalten, wie Feedback erhalten und gegeben werden kann (als Fehlerberichte oder Verbesserungsvorschläge), und wie man zur Softwareentwicklung beitragen kann. [interact]

    Jenkins website provides all required information: Downloads, Contribute and Participate. Jenkins issue tracker is also linked from the landing page and from the website footer.



    Genug für ein Badge!

    Die Informationen darüber, wie jemand beitragen kann, MÜSSEN den Prozess erklären (z.B. wie werden Pull-Requests verwendet?) (URL erforderlich) [contribution]
    Wir nehmen an, dass Projekte auf GitHub Issues und Pull-Requests verwenden, sofern nichts anders angegeben ist. Diese Information kann kurz sein, z.B., dass das Projekt Pull-Requests, einen Issue-Tracker oder eine Mailing-Liste verwendet (welche?)

    We have [Contributing Guidelines]https://github.com/jenkinsci/jenkins/blob/master/CONTRIBUTING.md] in the Jenkins core repository. Also, there is documentation for newcomer contributors available on https://jenkins.io/participate/ . For other core components we have an organization-wide contributing page on GitHub which references other resources



    Genug für ein Badge!

    Die Informationen darüber, wie jemand beitragen können, SOLLTEN die Anforderungen für akzeptable Beiträge (z.B. einen Hinweis auf jeden erforderlichen Programmierstandard) enthalten. (URL erforderlich) [contribution_requirements]
  • FLOSS Lizenz

    Unter welcher Lizenz/welchen Lizenzen ist das Projekt veröffentlicht?
    Bitte verwenden Sie das SPDX License Expression Format; Beispiele sind "Apache-2.0", "BSD-2-Clause", "BSD-3-Clause", "GPL-2.0+", "LGPL-3.0+", "MIT" und "(BSD-2-Clause OR Ruby)".



    Genug für ein Badge!

    Die vom Projekt entwickelte Software MUSS als FLOSS lizensiert veröffentlicht sein. [floss_license]
    FLOSS Software erfüllt die Open Source Definition oder die Free Software Definition. Beispiele für solche Lizenzen sind die CC0 , MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0 , Lesser GNU General Public License (LGPL) und die GNU General Public License (GPL) . Für unsere Zwecke bedeutet dies, dass die Lizenz: Die Software kann auch über andere Wege lizenziert werden (z.B. "GPLv2 oder proprietär" ist akzeptabel).

    The MIT license is approved by the Open Source Initiative (OSI).



    Genug für ein Badge!

    Es wird EMPFHOLEN, dass alle erforderlichen Lizenz(en) für die vom Projekt entwickelte Software von der Open Source Initiative (OSI) anerkannt werden. [floss_license_osi]
    Die OSI verwendet einen anspruchsvollen Genehmigungsprozess, um festzulegen, welche Lizenzen OSS sind.

    The MIT license is approved by the Open Source Initiative (OSI).



    Genug für ein Badge!

    Das Projekt MUSS die Lizenz(en) seiner Erzeugnisse an einem üblichen Ort in ihrem Quell-Repository veröffentlichen. (URL erforderlich) [license_location]
    Z.B. als eine Top-Level-Datei mit der Bezeichnung LICENSE oder COPYING. Lizenzdateinamen DÜRFEN eine Erweiterung wie ".txt" oder ".md" haben. Beachten Sie, dass dieses Kriterium nur eine Voraussetzung für das Quell-Repository ist. Sie müssen die Lizenzdatei NICHT hinzufügen, wenn Sie etwas aus dem Quellcode generieren (z.B. eine ausführbare Datei, ein Paket oder einen Container). Wenn Sie beispielsweise ein R-Paket für das Comprehensive R Archive Network (CRAN) generieren, befolgen Sie die Standard-CRAN-Praxis: Wenn die Lizenz eine Standardlizenz ist, verwenden Sie die Standard-Kurzlizenzspezifikation (um die Installation einer weiteren Kopie des Textes zu vermeiden) die LICENSE-Datei in einer Ausschlussdatei wie .Rbuildignore. Ebenso können Sie beim Erstellen eines Debian-Pakets einen Link in die Copyright-Datei zum Lizenztext in /usr/share/common-licenses einfügen und die Lizenzdatei vom erstellten Paket ausschließen (z.B. durch Löschen der Datei nach dem Aufruf von dh_auto_install). Wir empfehlen, maschinenlesbare Lizenzinformationen in generierten Formaten zu integrieren, wo dies praktisch ist.

    Non-trivial license location file in repository: https://github.com/jenkinsci/jenkins/blob/master/LICENSE.txt.


  • Dokumentation


    Genug für ein Badge!

    Das Projekt MUSS eine grundlegende Dokumentation für die vom Projekt entwickelte Software liefern. [documentation_basics]
    Diese Dokumentation muss in irgendeinem Medium sein (z.B. Text oder Video), das folgendes beinhaltet: wie man die Software installiert, wie man sie started, wie man sie benutzt (evtl. ein Tutorial mit Beispielen) und wie man sie sicher benutzt (z.B. was zu tun und zu lassen ist), wenn das ein passendes Einsatzgebiet für die Software ist. Die Sicherheitsdokumentation muss nicht lange sein. Das Projekt DARF Hypertext-Links zu Nicht-Projekt-Materialien als Dokumentation verwenden. Wenn das Projekt keine Software entwickelt, wählen Sie "nicht anwendbar" (N/A) aus.

    Genug für ein Badge!

    Das Projekt MUSS Referenzdokumentationen enthalten, die externe Schnittstellen (beides, Eingabe und Ausgabe) der vom Projekt entwickelten Software beschreiben. [documentation_interface]
    Die Dokumentation einer externen Schnittstelle erklärt einem Endbenutzer oder Entwickler, wie man sie benutzt. Dies beinhaltet auch eine Programmierschnittstelle (API), falls die Software eine hat. Wenn es sich um eine Bibliothek handelt, dokumentieren Sie die wichtigsten Klassen/Typen und Methoden/Funktionen, die aufgerufen werden können. Wenn es sich um eine Webanwendung handelt, definieren Sie ihre URL-Schnittstelle (häufig eine REST-Schnittstelle). Wenn es sich um eine Befehlszeilenschnittstelle handelt, dokumentieren Sie die Parameter und Optionen, die sie unterstützt. In vielen Fällen ist es am besten, wenn die meisten dieser Dokumente automatisch generiert werden, so dass diese Dokumentation mit der sich ändernden Software synchronisiert bleibt, aber dies ist nicht erforderlich. Das Projekt DARF Hypertext-Links zu Nicht-Projekt-Materialien als Dokumentation verwenden. Dokumentation DARF automatisch generiert werden (falls möglich ist dies oft der beste Weg). Die Dokumentation einer REST-Schnittstelle kann mit Swagger/OpenAPI erzeugt werden. Code-Interface-Dokumentation kann mit Werkzeugen wie JSDoc (JavaScript), ESDoc (JavaScript), pydoc (Python), devtools (R), pkgdown (R) und Doxygen (verschiedene) generiert werden. Nur Kommentare im Quelltext reicht nicht aus, um dieses Kriterium zu erfüllen; Es muss einen einfacheren Weg geben, um die Informationen zu sehen, ohne den ganzen Quellcode durchzulesen. Wenn das Projekt keine Software entwickelt, wählen Sie "nicht anwendbar" (N/A) aus.
  • Andere


    Genug für ein Badge!

    Die Projekt-Seiten (Website, Repository und Download-URLs) MÜSSEN HTTPS mit TLS unterstützen. [sites_https]
    Dies setzt voraus, dass die Projekt-Homepage-URL und die URL des Versionskontroll-Repositories mit "https:", nicht "http:" beginnt. Sie können kostenlose Zertifikate von Let's Encrypt erhalten. Projekte KÖNNEN dieses Kriterium implementieren, indem Sie (z. B.) GitHub-Pages verwenden, GitLab-Pages oder SourceForge project pages. Wenn Sie HTTP unterstützen, empfehlen wir Ihnen, den HTTP-Datenverkehr an HTTPS umzuleiten.

    Given only https: URLs.



    Genug für ein Badge!

    Das Projekt MUSS einen oder mehrere Mechanismen zur Diskussion (einschließlich der vorgeschlagenen Änderungen und Issues) haben, die durchsuchbar sind, bei denen Nachrichten und Themen durch URL adressiert werden, neue Personen an einigen der Diskussionen teilnehmen können und keine lokale Installation von proprietärer Software erfordern. [discussion]
    Beispiele für akzeptable Mechanismen umfassen archivierte Mailingliste(n), GitHub Issues und Pull-Request-Diskussionen, Bugzilla, Mantis und Trac. Asynchrone Diskussionsmechanismen (wie IRC) sind akzeptabel, wenn sie diese Kriterien erfüllen; Stellen Sie sicher, dass es einen URL-adressierbaren Archivierungsmechanismus gibt. Proprietäres JavaScript ist ungern gesehen aber erlaubt.

    GitHub supports discussions on issues and pull requests.



    Genug für ein Badge!

    Das Projekt SOLLTE Dokumentationen in englischer Sprache zur Verfügung stellen und in der Lage sein, Fehlerberichte und Kommentare zum Code in Englisch zu akzeptieren. [english]
    Englisch ist derzeit die Lingua Franca der Computertechnik; Wenn Englisch unterstützt wird, erhöht das die Anzahl der verschiedenen potenziellen Entwickler und Reviewer weltweit. Ein Projekt kann dieses Kriterium auch dann erfüllen, wenn die Hauptsprache der Kernentwickler nicht Englisch ist.

(Erweitert) Welche anderen Benutzer haben zusätzliche Rechte zum Bearbeiten dieses Badge-Antrag? Derzeit: []
Die meisten Projekte sollten dieses Feld ignorieren. Badge-Projekt-Einträge können immer vom Besitzer des Badge-Antrag-Besitzers (Ersteller), von den BadgeApp-Administratoren und von allen Personen bearbeitet werden, die sich für das GitHub-Repository anmelden können (wenn es sich um GitHub handelt). Wenn Sie möchten, dass jemand anderes diesen Eintrag bearbeiten kann und Sie bereits über Bearbeitungsrechte für diesen Projektausweiseintrag verfügen, können Sie zusätzlichen Benutzern Bearbeitungsrechte zuweisen. Geben Sie einfach "+" gefolgt von einer durch Kommas getrennten Liste von Integer-Benutzer-IDs ein. Diese Benutzer dürfen dann auch diesen Projekteintrag bearbeiten. Wenn Sie Inhaber des Badge-Antrags oder ein BadgeApp-Administrators sind, können Sie Benutzer aus dieser Liste entfernen, indem Sie "-" gefolgt von einer durch Kommas getrennten Liste von Integer-Benutzer-IDs eingeben. Wir erwarten, dass normalerweise nur jeweils eine Person einen bestimmten Eintrag bearbeiten wird. Diese App verwendet optimistische Sperren, um das Speichern veralteter Daten zu verhindern, wenn mehrere Benutzer gleichzeitig versuchen, einen Eintrag zu bearbeiten. Wenn Sie mehrere Editoren haben, empfehlen wir Ihnen, die Eintragsdaten inkrementell und oft zu speichern (das ist sowieso ratsam).



 Verbesserungs/Nacharbeits -Kontrolle 9/9

  • Öffentliches Versionskontroll Source Repository


    Genug für ein Badge!

    Das Projekt MUSS ein versiongesteuertes Quell-Repository haben, das öffentlich lesbar ist und eine URL hat. [repo_public]
    Die URL KANN die gleiche wie die Projekt-URL sein. Das Projekt KANN in bestimmten Fällen private (nichtöffentliche) Zweige verwenden, während die Änderung nicht öffentlich freigegeben wird (z. B. für die Behebung einer Sicherheitslücke, bevor sie veröffentlicht wird).

    Repository on GitHub, which provides public git repositories with URLs.



    Genug für ein Badge!

    Das Quell-Repository des Projekts MUSS verfolgen, welche Änderungen vorgenommen wurden, wer die Änderungen vorgenommen hat und wann die Änderungen vorgenommen wurden. [repo_track]

    Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.



    Genug für ein Badge!

    Um eine kollaborative Überprüfung zu ermöglichen, MUSS das Quell-Repository des Projekts Zwischenversionen für die Überprüfung zwischen Releases enthalten. Es MUSS NICHT nur endgültige Veröffentlichungen enthalten. [repo_interim]
    Projekte DÜRFEN sich entscheiden, bestimmte Zwischenversionen aus ihren öffentlichen Quell-Repositories auszulassen (z.B. diejenigen, die bestimmte nicht-öffentliche Sicherheitslücken beheben, niemals öffentlich freigegeben werden können, oder Material enthalten, das nicht legal veröffentlicht werden kann und nicht in der endgültigen Version enthalten ist).


    Genug für ein Badge!

    Es ist EMPFOHLEN, dass eine gemeinsame genutzte Versionskontrollsoftware (z.B. git oder mercurial) für das Source-Repository des Projekts verwendet wird. [repo_distributed]
    Git ist nicht speziell gefordert und Projekte können andere zentralisierte Versionskontrollsoftware (wie z.B. Subversion) mit Rechtfertigung verwenden.

    Repository on GitHub, which uses git. git is distributed.


  • Einzigartige Versionsnummerierung


    Genug für ein Badge!

    Die für Endbenutzer vorgesehenen Projektergebnisse MÜSSEN eine eindeutige Versionskennung für jede Freigabe haben. [version_unique]
    Dies DARF durch einer Vielzahl von Möglichkeiten, einschließlich einer Commit-IDs (wie z. B. git commit id oder mercurial changeset id) oder eine Versionsnummer, (einschließlich Versionsnummern, die semantische oder datebasierte Systeme wie YYYYMMDD verwenden) erfüllt werden.


    Gerade genug für ein Badge.

    Es wird erwartet, dass das Format Semantic Versioning (SemVer) für Veröffentlichungen verwendet wird. [version_semver]
    Andere Versionsnummerierungsschemata, wie z. B. Commit-IDs (wie z. B. git commit id oder mercurial changeet id) oder datebasierte Schemata wie YYYYMMDD, DÜRFEN als Versionsnummern verwendet werden, da sie eindeutig sind. Einige Alternativen können zu Problemen führen, denn die Benutzer können nicht leicht feststellen, ob sie aktuell sind. SemVer kann weniger hilfreich sein, um Software-Releases zu identifizieren, wenn alle Empfänger nur die neueste Version ausführen (z.B. ist es der Code für eine einzelne Website oder Internet-Service, der ständig durch kontinuierliche Updates aktualisiert wird).

    Jenkins project uses a scheme close to Semantic versioning for LTS releases: https://jenkins.io/download/lts/ . For weekly releases we use a 2-digit scheme



    Genug für ein Badge!

    Es wird erwartet, dass Projekte jede Freigabe innerhalb ihres Versionskontrollsystems identifizieren. Zum Beispiel wird erwartet, dass die Projekte, die git verwenden, jede Freigabe mit git-Tags identifizieren. [version_tags]
  • Versionshinweise


    Genug für ein Badge!

    Das Projekt MUSS zu jedem Update Releasenotes enthalten, die eine lesbare Zusammenfassung der wichtigsten Änderungen der Version sind, damit Benutzer/innen sehen können, ob sie aktualisieren sollten und was die Auswirkungen des Updades sind. Die Releasenotes MÜSSEN NICHT die Rohausgabe eines Versionskontrollprotokolls sein (z.B. die "git log" Befehlsergebnisse sind keine Release Notes). Für Projekte, deren Ergebnisse nicht für die Wiederverwendung an mehreren Standorten bestimmt sind (z.B. die Software für eine einzelne Website oder Dienstleistung) und eine kontinuierliche Lieferung verwenden, können Sie "N/A" auswählen. (URL erforderlich) [release_notes]
    Die Release Notes DÜRFEN auf vielfältige Weise implementiert werden. Viele Projekte bieten sie in einer Datei namens "NEWS", "CHANGELOG" oder "ChangeLog", optional mit Erweiterungen wie ".txt", ".md" oder ".html" an. Historisch bedeutete der Begriff "Change Log" ein Protokoll in dem jede Änderung festgehalten wird, aber um diese Kriterien zu erfüllen, benötigt es eine menschlich lesbare Zusammenfassung. Die Release Notes können stattdessen von Versionskontrollsystemmechanismen wie dem GitHub Release Workflow zur Verfügung gestellt werden.

    Genug für ein Badge!

    Die Release Notes MÜSSEN jede öffentlich bekannte Sicherheitslücke mit einer CVE-Zuweisung oder ähnlichem kennzeichnen, die in jeder neuen Version behoben sein wird, es sei denn, Benutzer können nicht die Software selbst aktualisieren, was normalerweise nicht der Fall ist. Wenn keine Release Notes vorhanden sind oder keine öffentlich bekannten Sicherheitslücken bekannt sind, wählen Sie "nicht anwendbar" (N/A). [release_notes_vulns]
    Wenn Benutzer die Software normalerweise nicht selbst auf ihren Computern aktualisieren können, sondern stattdessen auf eine/n Mittelsfrau/mann angewiesen sind, um das Upgrade durchzuführen (wie es bei einem Kernel und einer Low-Level-Software häufig der Fall ist), wählen Sie "nicht anwendbar" (N/A).

    All security releases provide links to Security advisories in the changelog. Example: https://jenkins.io/changelog/#v2.197


 Berichterstattung 8/8

  • Bug-Report Prozess


    Genug für ein Badge!

    Das Projekt muss einen Prozess für Benutzer enthalten, um Fehlerberichte zu senden (z. B. mit einem Issue Tracker oder eine Mailing-Liste). (URL erforderlich) [report_process]

    Jenkins Issue Tracker: https://issues.jenkins-ci.org/ . 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 .



    Genug für ein Badge!

    Das Projekt SOLLTE einen Issue Tracker für die Nachverfolgung einzelner Issues verwenden. [report_tracker]

    Jenkins Issue Tracker: https://issues.jenkins-ci.org/ . 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



    Genug für ein Badge!

    Das Projekt MUSS eine Mehrheit der in den letzten 2-12 Monaten eingereichten Fehlerberichte berücksichtigen; Die Antwort muss keine Korrektur enthalten. [report_responses]

    In the Jenkins project we invest in providing better response times in the issue tracker. See the Jenkins issue triage process for information about the current triage process and recommendations.

    As of Jul 21, 2020:

    • 488 defects were reported to the Jenkins core components in the last 12 months
    • 271 defects (55%) have been resolved
    • 186 issues (38%) received an initial response and/or explicit confirmation
    • 31 defects did not get a response

    We plan to introduce a Jenkins Bug Triage team to improve the response times and to ensure that all issues get processed (discussion in the developer mailing list).



    Genug für ein Badge!

    Das Projekt SOLLTE auf eine Mehrheit (>50%) der Verbesserungsvorschläge in den letzten 2-12 Monaten (einschließlich) reagieren. [enhancement_responses]
    Die Antwort DARF "nein" oder eine Diskussion über ihre Vorzüge sein. Das Ziel ist einfach, dass es einige Antworten auf einige Anfragen gibt, was darauf hinweist, dass das Projekt noch am Leben ist. Für die Zwecke dieses Kriteriums müssen die Projekte keine falschen Anfragen (z.B. von Spammern oder automatisierten Systemen) zählen. Wenn ein Projekt keine weiteren Verbesserungen vornimmt, wählen Sie bitte "Unerfüllt" und geben Sie die URL ein, die diesen Zustand den Benutzern klar macht. Wenn ein Projekt von der Anzahl der Verbesserungsvorschläge überwältigt wird, wählen Sie bitte "Unerfüllt" und erklären Sie die Situation.

    At the moment we do not regular triage of the enhancement requests, but we meet the criteria with the informal process. As of Jul 21, 2020, 203 issues were reported in the last 2-12 months (inclusinve), 105 of them (or 52%) have been already resolved or closed. The majority of other requests submitted users and non-core contributors got initial response. Issue query



    Genug für ein Badge!

    Das Projekt MUSS ein öffentlich zugängliches Archiv für Berichte und Antworten für die spätere Suche haben. (URL erforderlich) [report_archive]

    Jenkins Issue Tracker: https://issues.jenkins-ci.org/


  • Anfälligkeits-Prozessbericht


    Genug für ein Badge!

    Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) [vulnerability_report_process]
    z.B., eine klar benannte Mailing-Adresse auf https://PROJECTSITE/security, oft in der Form security@example.org. Dies KANN die gleiche sein wie die für den Fehlerberichtsprozess. Informationen über Schwachstellen können immer öffentlich sein, aber viele Projekte verfügen über einen privaten Schwachstellen-Berichtsmechanismus.

    Genug für ein Badge!

    Falls das Projekt einen Kanal zur Übertragung von Schwachstellen besitzt, dann MUSS diese Informationsübertragung privat ablaufen. (URL erforderlich) [vulnerability_report_private]
    Beispiele hierfür sind ein privater Defektbericht, der im Internet über HTTPS (TLS) oder eine mit OpenPGP verschlüsselte E-Mail verschickt wird. Wenn die Informationsübertragung von Schwachstellen immer öffentlich sind (also gibt es niemals private Informationsübertragung von Schwachstellen), wählen Sie "nicht anwendbar" (N/A).

    Genug für ein Badge!

    Das Projekts MUSS mindestens binnen 14 Tagen, auf jeden in den letzten 6 Monaten erhaltenen Anfälligkeitsbericht, reagieren. [vulnerability_report_response]
    Wenn in den letzten 6 Monaten keine Schwachstellen gemeldet wurden, wählen Sie "nicht anwendbar" (N/A).

    Vulnerability report are monitored by the Jenkins Security Team. This team monitors all incoming requests which are submitted according to the vulnerability reporting guidelines. For Jenkins core the security team handles the reports on its own, and the response time is usually less than 24 hours.


 Qualität 13/13

  • Produktivsystem


    Genug für ein Badge!

    Falls die vom Projekt entwickelte Software vor Benutzung kompiliert werden muss, MUSS das Projekt ein funktionierendes Buildsystem bereitstellen, das den Source Code automatisch in Software übersetzt. [build]
    Ein Build-System bestimmt, welche Aktionen durchgeführt werden müssen, um die Software neu zu bauen (und in welcher Reihenfolge) und führt dann diese Schritte aus. Zum Beispiel kann es einen Compiler aufrufen, um den Quellcode zu kompilieren. Wenn eine ausführbare Datei aus dem Quellcode erstellt wird, muss es möglich sein, den Quellcode des Projekts zu ändern und dann eine aktualisierte ausführbare Datei mit diesen Modifikationen zu erzeugen. Wenn die vom Projekt produzierte Software von externen Bibliotheken abhängt, muss das Build-System diese externen Bibliotheken nicht bauen. Wenn es keine Notwendigkeit gibt, irgendetwas zu bauen, um die Software zu verwenden, nachdem ihr Quellcode geändert wurde, wählen Sie "nicht anwendbar" (N/A).

    Genug für ein Badge!

    Es ist EMPFHOLEN, dass gewöhnliche Werkzeuge zum Kompiliren von Software benutzt wird. [build_common_tools]
    Beispielsweise, Maven, Ant, cmake, die Autotools, make, rake (Ruby) oder devtools (R).

    Genug für ein Badge!

    Das Projekt SOLLTE allein mit FLOSS Werkzeugen gebaut werden können. [build_floss_tools]

  • Automatisierte Test-Suite


    Genug für ein Badge!

    Das Projekt muss mindestens eine automatisierte Test-Suite verwenden, die öffentlich als FLOSS veröffentlicht wird (diese Test-Suite kann als separates FLOSS-Projekt gepflegt werden). [test]
    Das Projekt KANN mehrere automatisierte Test-Suiten benutzen (z. B. eine, die schnell läuft, eine andere, die gründlicher ist, aber spezielle Ausrüstung erfordert).

    Jenkins project includes unit and functional tests inside the main repository. In addition, there is a Jenkins Acceptance Test Harness test suite



    Genug für ein Badge!

    Eine Test-Suite SOLLTE in einer üblichen Weise für diese Programmiersprache aufrufbar sein. [test_invocation]
    Zum Beispiel, "make check", "mvn test", oder "rake test".

    Jenkins Core unit and integration test suites can be invoked using the standard Maven Surefire Plugin. JavaScript unit tests can be launched via YARN. See Jenkins Core - Testing Changes for more information.

    Acceptance Test Harness tests can be invoked using the standard Maven Surefire Plugin, the test repository is located in jenkinsci/acceptance-test-harness/



    Genug für ein Badge!

    Es wird erwartet, dass die Test-Suite die meisten (oder idealerweise alle) Code-Zweige, Eingabefelder und Funktionalitäten abdeckt. [test_most]


    Genug für ein Badge!

    Es wird erwartet, dass das Projekt eine kontinuierliche Integration durchführt (wo neuer oder geänderter Code häufig in ein zentrales Code-Repository integriert wird und automatisierte Tests auf diesen Ergebnissen durchgeführt werden). [test_continuous_integration]

    We use Jenkins-on-Jenkins: https://ci.jenkins.io/


  • Neue Funktionalitäts-Überprüfung


    Genug für ein Badge!

    Das Projekt MUSS allgemeine Grundregeln (formal oder nicht) haben, die als wesentliche neue Funktionalität der Software des Projektes hinzugefügt werden. Tests dieser Funktionalität sollten zu einer automatisierten Test-Suite hinzugefügt werden. [test_policy]
    Solange Grundregeln vorhanden sind, selbst wenn durch Mundpropaganda, sollten die Entwickler/innenTests für die automatisierte Test-Suite für große neue Funktionalität hinzufügen, wählen Sie "Met".

    Genug für ein Badge!

    Das Projekt MUSS nachweisen, dass die test_policy für das Hinzufügen von Tests in den jüngsten großen Änderungen an der Projektsoftware eingehalten wurde. [tests_are_added]
    Wichtige Funktionalitäten würden typischerweise in den Patchnotes erwähnt. Perfektion ist nicht erforderlich, nur Beweise dafür, dass Tests in der Praxis in der Regel der automatisierten Test-Suite hinzugefügt werden, wenn neue Hauptfunktionalität der Projektsoftware hinzugefügt wird.

    See the pull request history. Examples for major improvements



    Genug für ein Badge!

    Es wird erwartet, dass diese Richtlinien zum Hinzufügen von Tests (siehe test_policy ) in den Anweisungen für Änderungsvorschläge dokumentiert werden. [tests_documented_added]
    Allerdings ist auch eine informelle Regel akzeptabel, solange die Tests in der Praxis hinzugefügt werden.
  • Warnhinweise


    Genug für ein Badge!

    Das Projekt MUSS einen oder mehrere Compiler-Warn-Flags, einen "sicheren" Sprachmodus oder ein separates "Linter" -Tool verwenden, um nach qualitativen Fehlern im Code oder gängigen einfachen Fehlern zu suchen, wenn es mindestens ein FLOSS-Tool gibt, das dieses Kriterium implementieren kann in der gewählten sprache [warnings]
    Beispiele für Compiler-Warn-Flags sind gcc / clang "-Wall". Beispiele für einen "sicheren" Sprachmodus beinhalten JavaScript "use strict" und perl5's "use warnings". Ein separates "Linter" -Tool ist einfach ein Werkzeug, das den Quellcode untersucht, um nach qualitativen Fehlern im Code oder gängigen einfachen Fehlern zu suchen. Diese werden in der Regel im Quellcode aktiviert oder in den Einstellungen.

    Our Jenkins core and library Parent POM includes standard static analysis tools like SpotBugs, Animal Sniffer, Maven Enforcer (for dependency and binary API checks), etc. Same applies to the plugin POM.



    Genug für ein Badge!

    Das Projekt MUSS auf Warnungen reagieren. [warnings_fixed]
    Dies sind die Warnungen, die durch die Umsetzung des warnings Kriteriums identifiziert wurden. Das Projekt sollte Warnungen beheben oder im Quellcode als falsch positives Ergebnis markieren. Idealerweise gibt es keine Warnungen, aber ein Projekt DARF einige Warnungen akzeptieren (typischerweise weniger als 1 Warnung pro 100 Zeilen oder weniger als 10 Warnungen).

    Jenkins core, modules and libraries address all high-severity warnings and acknowledge a number of medium-severity warnings which is within the "1 warning per 100 lines" requirement. There is ongoing project to cleanup the Jenkins core warnings entirely ([JENKINS-36716])(https://issues.jenkins-ci.org/browse/JENKINS-36716).



    Gerade genug für ein Badge.

    Es wird erwartet, dass Projekte Warnungen in der Software, die durch das Projekt produziert wird, sorgfältig berücksichtigen. [warnings_strict]
    Bei manchen Projekten können einige Warnungen effektiv nicht aktiviert werden. Was benötigt wird, ist ein Beleg dafür, dass das Projekt danach strebt, Warnungen zu aktivieren, wo es möglich ist, so dass Fehler frühzeitig erkannt werden.

    Jenkins core uses high and medium thresholds for static analysis warnings. ([JENKINS-36716])(https://issues.jenkins-ci.org/browse/JENKINS-36716 intends to implement and maintain higher code quality standards.


 Sicherheit 16/16

  • Wissen über sichere Entwicklungspraktiken


    Genug für ein Badge!

    Das Projekt MUSS mindestens einen primären Entwickler haben, der weiß wie man Sicherheitssoftware entwerfen kann. (Siehe "Details" für spezifische Anforderungen.) [know_secure_design]
    Dies erfordert das Verständnis der folgenden Designprinzipien, einschließlich der 8 Prinzipien von Saltzer und Schroeder:
    • Wirtschaftlichkeit des Mechanismus (halten Sie das Design so einfach und klein wie möglich, z. B. durch umfassende Vereinfachungen)
    • Fehlersichere Vorgaben (Zugriffsentscheidungen sollten standardmäßig verweigert werden und die Installation der Projekte sollte standardmäßig sicher sein)
    • Vollständige Vermittlung (jeder Zugang, der begrenzt werden kann, muss auf Autorität überprüft werden und nicht umgangen werden können)
    • Offenes Design (Sicherheitsmechanismen sollten nicht von der Unkenntnis der Angreifer über das Designs abhängig gemacht werden, sondern stattdessen auf leichter geschützte und geänderte Informationen wie Schlüssel und Passwörter)
    • Trennung von Privilegien (Idealerweise sollte der Zugriff auf wichtige Objekte von mehr als einer Bedingung abhängen, so dass die Beseitigung eines Schutzsystems keinen vollständigen Zugriff ermöglicht. z.B., Multi-Faktor-Authentifizierung wie die Erfordernis eines Passwortes und eines Hardware-Token ist stärker als die Single-Faktor-Authentifizierung)
    • So wenige Privilegien wie möglich (Prozesse sollten nur mit den geringsten Privilegien laufen)
    • So wenig gemeinsame Mechanismen wie möglich (Das Design sollte die Mechanismen minimieren, die von mehreren Benutzern gemeinsam verwendet werden und von allen Benutzern abhängig sind, z.B. Verzeichnisse für temporäre Dateien)
    • Psychologische Akzeptanz (Die menschliche Schnittstelle muss Benutzerfreundlichkeit entworfen werden - Design für "geringes Erstaunen" kann dabei helfen)
    • Begrenzte Angriffsfläche (die Angriffsfläche - die Menge der verschiedenen Punkte, wo ein Angreifer versuchen kann, Daten einzugeben oder zu extrahieren - sollte begrenzt sein)
    • Eingabevalidierung mit Positivliste (Eingaben sollten in der Regel überprüft werden, um festzustellen, ob sie gültig sind, bevor sie akzeptiert werden; Diese Validierung sollte Postitivlisten verwenden (die nur bekannte gute Werte akzeptieren), nicht Negativlisten (die versuchen, bekannte schlechte Werte aufzulisten)).
    Ein "Primärer Entwickler" in einem Projekt ist jedermann, der mit der Codebasis des Projekts vertraut ist, der in der Lage ist Änderungen daran vorzunehmen und von den meisten anderen Teilnehmern des Projekts als solches anerkannt wird. Ein primärer Entwickler hat üblicherweise im vergangen Jahr eine Reihe von Aufgaben übernommen (Code, Dokumentation oder Beantwortung von Fragen). Die Entwickler würden typischerweise als primäre Entwickler betrachtet, wenn sie das Projekt initiiert haben (und das Projekt nicht vor mehr als drei Jahre verlassen haben), die Möglichkeit haben, Informationen zu Schwachstellen über einen privaten Berichtskanal zu erhalten (falls vorhanden), neuen Code zum Projekt entgegennehmen zu können, oder die endgültige Freigaben der Projektsoftware durchzuführen. Wenn es nur einen Entwickler gibt, ist diese Person der primäre Entwickler.

    The Jenkins project has a Security Team which includes several Jenkins core maintainers with experience working on security issues. Some of these contributors work professionally as security engineers and regularly implement and review software designs to ensure high security standards.



    Genug für ein Badge!

    Mindestens einer der primären Entwickler des Projekts MUSS über weitläufige Arten von Fehlern, die zu Schwachstellen in dieser Art von Software führen, Bescheid wissen sowie mindestens eine Methode, um jede von ihnen zu beseitigen oder zu mildern. [know_common_errors]
    Beispiele (je nach Art der Software) beinhalten SQL-Injektion, OS-Injektion, klassischer Pufferüberlauf, Cross-Site-Scripting, fehlende Authentifizierung und fehlende Autorisierung. Siehe die CWE/SANS top 25 oder OWASP Top 10 für häufig verwendete Listen.

    The Jenkins project has a Security Team which includes several Jenkins developers who have experience with working on security issues and provide documentation for other Jenkins developers how to address common vulnerabilities. Jenkins core maintainers and the release team are also represented on the Security team.


  • Verwende grundlegend gute kryptographische Praktiken

    Beachte, dass einige Software keine kryptographischen Mechanismen verwenden muss.

    Genug für ein Badge!

    Die vom Projekt entwickelte Software MUSS standardmäßig nur kryptografische Protokolle und Algorithmen verwenden, die öffentlich sind und von Experten überprüft wurden (falls kryptographische Protokolle und Algorithmen verwendet werden). [crypto_published]
    Diese kryptographischen Kriterien gelten nicht immer, da einige Software keine direkten kryptografischen Funktionen benötigt.

    The Jenkins project uses standard open-source implementations of cryptographic protocols and algorithms (e.g. implemented by JVM, Bouncy Castle, MINA SSH, and other open-source libraries like eddsa for its Ed25519 implementation). There are also standard APIs offered to the plugin developers (e.g. for storing secrets).



    Genug für ein Badge!

    Wenn die Software, die durch das Projekt produziert wird, eine Anwendung oder Bibliothek ist, und ihr Hauptzweck nicht die Kryptographie ist, dann SOLLTE sie lediglich Software einbinden, die speziell für kryptographische Funktionen entworfen ist; Sie SOLLTE NICHT eine eigene Implementierung vornehmen. [crypto_call]

    The Jenkins core and its modules do not implement cryptography on their own in recent versions. They depend on open-source libraries which provide cryptography functions. There are historical cryptography APIs offered in Jenkins, but their internal implementations have been replaced by open-source cryptography libraries used in the project.

    Additional notes about previous releases that are no longer supported:

    • Jenkins Remoting layer used to implement encryption on its own in the JNLP3 protocol. This protocol was deprecated in Dec 2017 (Remoting 3.15) and then completely removed from the codebase in Dec 2019 (Remoting 3.40)
    • The Jenkins core used to include cryptography implementations, e.g. a Jenkins-specific fork of the abandoned Trilead SSH library. It was removed from Jenkins 2.186 in July 2019 and is only included as detached plugin for backward compatibility with plugins depending on it, but not used by Jenkins itself.


    Genug für ein Badge!

    Alle Funktionalitäten in der vom Projekt entwickelten Software, die von Kryptographie abhängigen, MÜSSEN mit FLOSS implementiert werden. [crypto_floss]

    Jenkins core is fully FLOSS, as well as its dependencies.



    Genug für ein Badge!

    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software, MÜSSEN Standard-Keylängen verwenden, die die NIST-Mindestanforderungen bis zum Jahr 2030 erfüllen (wie im Jahr 2012 festgelegt). Es MUSS möglich sein, die Software so zu konfigurieren, dass kürzere Keylängen vollständig deaktiviert werden können. [crypto_keylength]
    Diese minimalen Bitlängen sind: symmetric key 112, factoring modulus 2048, discrete logarithm key 224, discrete logarithmic group 2048, elliptic curve 224, and hash 224 (das Passworthashing ist nicht von dieser Bitlänge abgedeckt, weitere Informationen zum Passworthashing finden sich im crypto_password_storage Kriterium). Siehe http://www.keylength.com für einen Vergleich von Keylängen Empfehlungen von verschiedenen Organisationen. Die Software KANN kleinere Keylängen in einigen Konfigurationen erlauben (idealerweise nicht, da dies Downgrade-Angriffe erlaubt, aber kürzere Keylängen sind manchmal für die Interoperabilität notwendig).

    The Jenkins core generally does not manage the key lengths in the codebase. We use the default values provided by the recent versions of cryptography libraries. One of the exceptions is a CryptoConfidentialKey used in hudson.util.Secret and a few other locations. These occurrences use AES 128 by default, and it is compliant with the length requirement for symmetric keys.



    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software MÜSSEN NICHT von defekten kryptographischen Algorithmen abhängen (z.B. MD4, MD5, Single DES, RC4, Dual_EC_DRBG) oder Chiffre-Modi verwenden, die dem Kontext unangemessen sind, außer sie sind notwendig, um kompatible Protokolle bereit zu stellen (wenn das Protokoll in der neusten Version in der Zielumgebung zum Einsatz kommt, die Zielumgebung solch in Protokoll erfordert und das Zielsystem keine sicherere Alternative anbietet). Die Dokumentation MUSS auf jegliche Sicherheitsrisiken hinweisen und bekannte Vorsichtsmaßnahmen beschreiben, sollten unsichere Protokolle unumgäglich sein. [crypto_working]
    Der EZB-Modus ist fast nie angemessen, da er identische Blöcke innerhalb des Geheimtextes aufdeckt, wie der ECB-Pinguin zeigt. Der CTR Modus ist oft unangemessen, da er keine Authentifizierung durchführt und Duplikate verursacht, wenn eine Eingabe wiederholt wird. In vielen Fällen ist es am besten, einen Block-Chiffre-Algorithmus-Modus zu wählen, der entworfen wurde, um Geheimhaltung und Authentifizierung zu kombinieren, z.B. Galois/ Counter Mode (GCM) und EAX. Projekte KÖNNTEN Benutzern erlauben, defekte Mechanismen zu ermöglichen (z.B. während der Einrichtung), falls nötig für Kompatibilität, aber dann wissen die Benutzer, dass sie es tun.

    We do NOT use broken cryptography algorithms for security mechanisms inside the Jenkins core or modules. In some cases MD5 is used to produce unique keys for Jenkins objects which are not used in a security context. Such objects have soft uniqueness requirements, and potential collisions do not compromise the Jenkins security or sensitive data.



    Genug für ein Badge!

    Die Standard-Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN NICHT nicht von kryptographischen Algorithmen oder Modi mit bekannten schweren Schwächen abhängen (z.B. SHA-1-Kryptographie-Hash-Algorithmus oder CBC-Modus in SSH). [crypto_weaknesses]
    Sorgen über den CBC-Modus in SSH werden in CERT: SSH CBC vulnerability erläutert.

    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.



    Genug für ein Badge!

    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software SOLLTEN ein perfektes Vorwärtsgeheimnis für wichtige Vereinbarungsprotokolle implementieren, so dass ein Sitzungsschlüssel, der aus einer Reihe von Langzeitschlüsseln abgeleitet wird, nicht beeinträchtigt werden kann, wenn einer der Langzeitschlüssel in der Zukunft kompromittiert wird. [crypto_pfs]

    In the majority of use-cases we use the default forward secrecy provided by 3rd-party open-source libraries (e.g. for establishing SSH connections). Same for HTTPS, the entire implementation is supplied by external libraries or projects (e.g. Eclipse Jetty bundled in the Jenkins core and used as a default web container).

    The only exception is the Jenkins Remoting library that includes an implementation of the JNLP4-connect protocol for networking between the Jenkins server and agents. This protocol uses the standard TLS encryption layer provided by JVM (default version). As of Jenkins 2.235.1 LTS Jenkins supports Java 8 (TLS 1.2 by default, no TLS 1.3 implementation in OpenJDK) and Java 11 (TLS 1.2 or 1.3 are provided). TLS 1.2 does not enforce perfect forward secrecy by default, but users of Jenkins can enforce TLS 1.3 and forward secrecy with OpenJDK 11 or with other JVMs for Java 8/11. Jenkins admins can also elect to block the JNLP4-connect protocol over TCP, and to use the WebSocket connection over HTTP/HTTPS, in which case the encryption is delegated to the web server and reverse proxies.



    Genug für ein Badge!

    Wenn die vom Projekt erzeugte Software Passwörter für die Authentifizierung von externen Benutzern speichert, MÜSSEN die Passwörter als iterierte Hashes mit einem per-User-Salt unter Verwendung eines Key-Stretching (iterierten) Algorithmus (z.B. PBKDF2, Bcrypt oder Scrypt) gespeichert werden. [crypto_password_storage]
    Dieses Kriterium gilt nur, wenn die Software die Authentifizierung von Benutzern mit Passwörtern erzwingt, wie z.B. bei serverseitige Webanwendungen. Es gilt nicht in Fällen, in denen die Software Kennwörter für die Authentifizierung in andere Systeme speichert (z.B. die Software implementiert einen Client für ein anderes System), da zumindest Teile dieser Software oft Zugriff auf das Passwort im Klartext haben müssen.

    In Jenkins we provide a private security realm which stores password hashes in the local filesystem database. This implementation uses BCrypt, and hence it is compatible with the requirements. It is also possible to use external authentication services (e.g. LDAP) which do not store user passwords in Jenkins. Jenkins Security Realm documentation



    Genug für ein Badge!

    Die Sicherheitsmechanismen innerhalb der vom Projekt entwickelten Software MÜSSEN alle kryptographischen Schlüssel und Nonces mit einem kryptographisch sicheren Zufallszahlengenerator erzeugen und DARF NICHT mit Generatoren arbeiten, die kryptographisch unsicher sind. [crypto_random]
    Ein kryptographisch sicherer Zufallszahlengenerator kann ein Hardware-Zufallszahlengenerator sein oder es kann ein kryptographisch sicherer Pseudozufallszahlengenerator (CSPRNG) sein, der einen Algorithmus wie Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow oder Fortuna verwendet. Beispiele für Aufrufe von sicheren Zufallszahlengeneratoren umfassen Java's java.security.SecureRandom und JavaScript's window.crypto.getRandomValues. Beispiele für Anrufe von unsicheren Zufallszahlengeneratoren sind Java's java.util.Random und JavaScript's Math.random.

    In the Jenkins core and modules we use the standard secure random number generator provided by the JVM. There are no custom implementations within the codebase.


  • Gesicherte Zustellung gegen Man-in-the-Middle (MITM) Angriffe


    Genug für ein Badge!

    Das Projekt MUSS einen Auslieferungsmechanismus verwenden, der den MITM-Angriffen entgegenwirkt. Die Verwendung von https oder ssh + scp ist akzeptabel. [delivery_mitm]
    Ein noch stärkerer Mechanismus ist die Freigabe der Software mit digital signierten Paketen, da dies Angriffe auf das Verteilungssystem verringert, aber das funktioniert nur, wenn die Benutzer sicher sein können, dass die öffentlichen Schlüssel für Signaturen korrekt sind und wenn die Benutzer die Signatur tatsächlich überprüfen.

    The Jenkins project uses HTTPS for the entire infrastructure and delivery mechanisms with the exception of Update Center Mirrors (tracked as INFRA-266). Mirrors are used to deliver Jenkins core, native packages and plugin binaries.

    • For the Jenkins WAR file distributions, checksums for current releases can be retrieved from the https://jenkins.io/download/ page. Additionally, the war files are signed and can be checked using jarsigner.
    • All official Jenkins native packages and installers are signed by the project, and this signature can be verified upon delivery by using a package manager.
    • To ensure that the delivered plugins are not tampered, the Jenkins project provides SHA-256 checksums which are accessible over HTTPS from the Update Center JSON file which is retrieved over HTTPS in the default configuration. In addition to that, the JSON file itself is signed using SHA-512. Jenkins verifies the checksums upon download of plugins in the update center client logic.

    Jenkins users can also set up a pure HTTPS delivery for all Jenkins artifacts by deploying their own update center by using the update center generator provided by the Jenkins project. This generator downloads all artifacts and metadata from the Jenkins Maven repository over HTTPS.

    In addition to plugins and distributions, Jenkins update sites also list downloadable tools supplied by plugins (e.g. Maven, Gradle, AdoptOpenJDK). These tools are downloaded from external locations which may not implement the secure delivery chain as we depend on other projects serving files securely (tracked as JENKINS-55659). Such tool downloads are opt-in, none of the tools are enabled and installed by default. The Jenkins project does not provide guarantees for external tool downloads.



    Genug für ein Badge!

    Ein kryptographischer Hash (z.B. sha1sum) MUSS NICHT über http abgerufen und ohne Überprüfung einer kryptographischen Signatur verwendet werden. [delivery_unsigned]
    Diese Hashes können im Transit verändert werden.

    Jenkins cryptographic hashes are retrieved over HTTPS from the Jenkins Maven repository. Checksums are also accessible over HTTPS from the Update Center JSON file which is retrieved over HTTPS by default (since 2017) and additionally, a signature for itself in a canonical form is included and verified by Jenkins.


  • Öffentlich bekannte Schwachstellen wurden behoben


    Genug für ein Badge!

    Es DARF KEINE ungepatchte Schwachstelle von mittlerer oder höher Schwere enthalten sein, die seit mehr als 60 Tagen öffentlich bekannt ist. [vulnerabilities_fixed_60_days]
    Die Sicherheitslücke, muss vom Projekt selbst gepatched und freigegeben werden (Patches woanders entwickelt werden). Eine Sicherheitsücke wird (für diesen Zweck) öffentlich bekannt, sobald es einen CVE mit öffentlich freigegebenen nicht bezahlten Informationen hat (veröffentlicht beispielsweise in der National Vulnerability Database) oder wenn das Projekt informiert und die Informationen der Öffentlichkeit zugänglich gemacht wurden (evtl. durch das Projekt). Eine Sicherheitslücke ist mittel- bis scherwiegend, wenn ihr CVSS 2.0 Basis-Score 4 oder höher ist. Hinweis: Das bedeutet, dass Benutzer bis zu 60 Tage für alle Angreifer weltweit anfällig bleiben können. Dieses Kriterium ist oft viel einfacher zu treffen als das, was Google empfiehlt in Rebooting responsible disclosure, weil Google empfiehlt, dass die 60-Tage-Periode beginnen, wenn das Projekt benachrichtigt wird selbst dann wenn der Bericht nicht öffentlich ist.

    There are no such vulnerabilities in the Jenkins Core and modules. While we strive to keep library dependencies updated, some dependencies included in the Jenkins core have known vulnerabilities. In such cases, we determine whether these vulnerabilities are exploitable in Jenkins, and if so, address them. Otherwise we do not consider these to be vulnerabilities in Jenkins.

    There are some unpatched vulnerabilities in plugins as listed in security advisories, but plugins are not in the scope for this certification. In the case of high severity issues the plugins are usually delisted from the Jenkins update centers. In all cases, warnings are presented to administrators of Jenkins instances that have plugins with publicly known vulnerabilities installed.



    Genug für ein Badge!

    Projekte SOLLTEN alle kritischen Schwachstellen schnell nachdem sie gemeldet wurden beheben. [vulnerabilities_critical_fixed]

    Critical vulnerabilities in the Jenkins core are handled by the Jenkins Security Team. This team reviews all incoming reports and prioritizes and fixes them. Critical vulnerabilities are prioritized as a top priority, and additional subject-matter experts may be involved if needed. For example, in 2015 the Jenkins project was able to analyze and fix the public class deserialization attack disclosure earlier than all other affected projects/vendors. In addition to that, we published a mitigation guide within less than 24 hours after the announcement.


  • Andere Sicherheitsissues


    Genug für ein Badge!

    Die öffentlichen Repositories MÜSSEN NICHT gültige private Zugriffsdaten enthalten (z.B. ein funktionierendes Passwort oder einen privaten Schlüssel), die den öffentlichen Zugriff einschränken sollen. [no_leaked_credentials]
    Ein Projekt DARF "Beispiel"-Zugriffsdaten für Tests und unwichtige Datenbanken herausgeben, solange sie nicht den öffentlichen Zugang einschränken sollen.

    The Jenkins core repository or other public repositories do not include any credentials in plain text.


 Analyse 8/8

  • Statische Codeanalyse


    Genug für ein Badge!

    Mindestens ein Tool zur Analyse statischer Codes (über Compiler-Warnungen und "sichere" Sprachmodi hinaus) MUSS vor der Veröffentlichung auf jede vorgeschlagene größere Produktionsversion der Software angewendet werden, wenn mindestens ein FLOSS-Tool dieses Kriterium in der ausgewählten Sprache implementiert . [static_analysis]
    Ein Tool zur statischen Codeanalyse untersucht den Softwarecode (als Quellcode, Zwischencode oder ausführbare Datei), ohne ihn mit bestimmten Eingaben auszuführen. Für dieses Kriterium zählen Compilerwarnungen und "sichere" Sprachmodi nicht als statische Codeanalyse-Tools (diese vermeiden typischerweise eine tiefgreifende Analyse, da Geschwindigkeit entscheidend ist). Beispiele für solche Tools zur statischen Codeanalyse sind cppcheck, clang static analyzer, FindBugs (einschließlich FindSecurityBugs), PMD, Brakeman, Coverity Quality Analyzer, SonarQube, Codacy und HP Enterprise Fortific Static-Code-Analyzer. Mehr Tools finden Sie beispielsweise in der Wikipedia-Liste von Tools zur statischen Codeanalyse, OWASP Informationen zur statischen Code-Analyse , NIST-Liste der Quellcode-Sicherheitsanalyse-Tools und Wheelers Liste der statischen Analyse-Tools. Das SWAMP ist eine kostenlose Plattform zur Bewertung von Schwachstellen in Software mit einer Vielzahl von Tools. Wenn für die verwendete (n) Implementierungssprache (n) keine statischen FLOSS-Analysewerkzeuge verfügbar sind, wählen Sie "N/V".

    We use SpotBugs, Animal Sniffer, Maven Enforcer Plugin as a part of the build/release pipelines



    Genug für ein Badge!

    Es wird davon ausgegangen, dass mindestens eines der statischen Analysewerkzeuge, die für das statische Analysekriterium verwendet wurde, inklusive der Regeln oder Ansätze, um nach gemeinsamen Schwachstellen in der analysierten Sprache oder Umgebung zu suchen. [static_analysis_common_vulnerabilities]
    Statische Analysetools, die speziell dafür entwickelt wurden, nach Schwachstellen zu suchen, finden diese eher. Das heißt, dass die Verwendung von statischen Tools in der Regel helfen wird einige Probleme zu finden. Wir schlagen dies vor, aber erwarten es für das "passing" -Level-Badge nicht.

    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.



    Genug für ein Badge!

    Alle mittel- und hochgradig ausnutzbaren Schwachstellen, die mit statischer Codeanalyse entdeckt wurden, MÜSSEN nach der Entdeckung rechtzeitig behoben werden. [static_analysis_fixed]
    Eine Sicherheitsanfälligkeit ist mittel- bis hochgradig schwerwiegend, wenn ihr CVSS 2.0 Wert 4 oder höher ist.

    In the Jenkins core there were several security issues reported by dependency scanning tools. They were timely analyzed and fixed if the vulnerability was confirmed. So far we did not get any confirmed medium/high severity vulnerabilities reported by a static code analysis tool.

    Jenkins plugins are not in the scope for this certification



    Genug für ein Badge!

    Es wird EMPFOHLEN, dass eine statische Quellcode-Analyse bei jedem Commit oder zumindest täglich ausgeführt wird. [static_analysis_often]

    We use SpotBugs, Animal Sniffer, Maven Enforcer Plugin as a part of the build/release pipelines


  • Dynamische Codeanalyse


    Gerade genug für ein Badge.

    Es ist EMPFHOLEN, dass mindestens ein dynamisches Analyse-Tool auf jede vorgeschlagene größere Veröffentlichung der Software vor seiner Freigabe angewendet wird. [dynamic_analysis]
    Ein dynamisches Analyse-Tool untersucht die Software, indem es sie mit bestimmten Eingaben ausführt. Beispielsweise DARF das Projekt ein Fuzzing-Tool verwenden (z.B. American Fuzzy Lop) oder einen Web Application Scanner (z.B. OWASP ZAP oder w3af). In einigen Fällen ist das OSS-Fuzz Projekt bereit, Fuzz-Tests auf Ihr Projekt anzuwenden. Für die Zwecke dieses Kriteriums muss das dynamische Analyse-Tool die Eingaben in irgendeiner Weise variieren, um nach verschiedenen Arten von Problemen zu suchen oder eine automatisierte Test-Suite mit mindestens 80% Abdeckung. Die Wikipedia-Seite zur dynamischen Analysen und die OWASP Seite auf Fuzzing nennen einige dynamische Analyse-Tools. Das Analyse-Tool(s) DARF für der Suche nach Sicherheitslücken eingesetzt werden, aber das ist nicht erforderlich.

    We do not use dynamic analysis tools as a part of our CI/CD pipeline. Some Jenkins users run scans and sometimes report vulnerabilities to the project, but it is quite rare.



    Genug für ein Badge!

    Es ist EMPFHOLEN, dass die vom Projekt entwickelte Software, falls sie Software von einer Speicher-unsicheren Sprache (z.B. C oder C ++) enthält, regelmäßig mindestens ein dynamisches Werkzeug (z.B. ein Fuzzer oder ein Web-Anwendungs-Scanner) in Kombination mit einem Mechanismus zur Erkennung von Speichersicherheitsproblemen wie Puffer-Overwrites verwendet. Wenn das Projekt keine Software entwickelt, die in einer Speicher-unsicheren Sprache geschrieben ist, wählen Sie "nicht anwendbar" (N/A). [dynamic_analysis_unsafe]
    Beispiele für Mechanismen zur Erkennung von Arbeitsspeicher Sicherheitsproblemen sind Adresse Sanitizer (ASAN) (verfügbar in GCC und LLVM), Memory Sanitizer und valgrind. Andere möglicherweise verwendete Werkzeuge sind Thread Sanitizer und Undefined Behavior Sanitizer. Weit verbreitete Assertions würden auch funktionieren.

    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.



    Genug für ein Badge!

    Es ist EMPFHOLEN, dass die vom Projekt entwickelte Software viele run-time assertions einbindet, die während der dynamischen Analyse überprüft werden. [dynamic_analysis_enable_assertions]

    Jenkins project does not use dynamic analysis tools as a part of the CI/CD pipeline. On the other hand, Jenkins instances produce run-time events (logs, metrics, etc.) which are exposed to monitoring tools and can be used for dynamic analysis



    Genug für ein Badge!

    Alle mittel- und hochgradig ausnutzbaren Schwachstellen, die mit dynamischer Codeanalyse entdeckt werden, MÜSSEN zügig behoben werden, nachdem sie bestätigt wurden. [dynamic_analysis_fixed]
    Eine Sicherheitslücke ist von mittlerem bis hohem Schweregrad, wenn ihr CVSS 2.0 Basis-Score 4 ist. Wenn Sie keine dynamische Codeanalyse ausführen und somit keine Schwachstellen auf diese Weise finden, wählen Sie "nicht anwendbar" (N/A).

    We do not use dynamic analysis tools as a part of our CI/CD pipeline



Die Daten sind unter der Creative Commons Attribution 3.0-Lizenz oder Nachfolder (CC-BY-3.0+) verfügbar, bereitgestellt von der Core Infrastructure Initiative unter den Nutzungsbedingungen. Es ist allen erlaubt, die Daten zu teilen und anzupassen, müssen aber einen angemessene Hinweis auf den Urheber geben. Bitte geben Sie als Urheber Oleg Nenashev und die CII Best Practices Badge Mitwirkenden an.

Projekt Badge Eintrag im Besitz von: Oleg Nenashev.
Eintrag erstellt auf 2019-12-26 14:21:18 UTC, zuletzt aktualisiert auf 2020-07-22 09:53:41 UTC. Letztes erreichtes Badge auf 2020-07-21 12:13:13 UTC.

Zurück