BadgeApp

Grundlagen 12/12 ●

Identifizierung

Was ist der von Menschen lesbare Name des Projekts?
Hinweis: Andere Projekte können den selben Namen benutzen.

Was ist eine Kurzbeschreibung des Projektes?

Apache Syncope is an Open Source system for managing digital identities in enterprise environments, implemented in Java EE technology and released under Apache 2.0 license.

Wie lautet die URL für das Projekt (vollständig)?
https://syncope.apache.org/

Was ist die URL für das Versionskontroll-Repository (es kann mit der Projekt-URL identisch sein)?
https://git-wip-us.apache.org/repos/asf/syncope.git

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".

Implementation languages

Was ist die Common Platform Enumeration (CPE) Name für das Projekt (wenn es einen gibt)?
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.
Basic project website content

Criterion [description_good]
Erfüllt

Unerfüllt

?

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).

General description in home page (https://syncope.apache.org/). Reference scenario for Identity and Access Manager in https://syncope.apache.org/iam-scenario.html

Criterion [interact]
Erfüllt

Unerfüllt

?

The project website MUST provide information on how to: obtain, provide feedback (as bug reports or enhancements), and contribute to the software. ^[interact]

Download binaries: https://syncope.apache.org/downloads.html Check out sources: https://syncope.apache.org/source-repository.html Feedback: https://syncope.apache.org/issue-tracking.html Contribute: https://syncope.apache.org/contributing.html

Criterion [contribution]
Erfüllt

Unerfüllt

?

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 nicht anders angegeben ist. Diese Information kann kurz sein, z.B., dass das Projekt Pull-Requests, einen Issue-Tracker, oder eine Mailing-Liste verwendet (welche?)

https://syncope.apache.org/contributing.html#How_to_contribute

Criterion [contribution_requirements]
Erfüllt

Unerfüllt

?

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]}

Build instructions (http://syncope.apache.org/building.html) and contributor guidelines (https://syncope.apache.org/contributing.html) describe how to contribute alongside with acceptance criteria. Those checks are also automatically checked by our CI system.
FLOSS License

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)".

License
Criterion [floss_license]
Erfüllt

Unerfüllt

?
Die vom Projekt entwickelte Software MUSS als FLOSS lizensiert veröffentlicht sein. ^{[floss_license]}
FLOSS is software released in a way that meets the Open Source Definition or Free Software Definition. Examples of such licenses include the CC0, MIT, BSD 2-clause, BSD 3-clause revised, Apache 2.0, Lesser GNU General Public License (LGPL), and the GNU General Public License (GPL). For our purposes, this means that the license MUST be:
The software MAY also be licensed other ways (e.g., "GPLv2 or proprietary" is acceptable).
Criterion [floss_license_osi]
Erfüllt

Unerfüllt

?

It is SUGGESTED that any required license(s) for the software produced by the project be approved by the Open Source Initiative (OSI). ^{[floss_license_osi]}
Die OSI verwendet einen anspruchsvollen Genehmigungsprozess, um festzulegen, welche Lizenzen OSS sind.

Criterion [license_location]
Erfüllt

Unerfüllt

?

The project MUST post the license(s) of its results in a standard location in their source repository. (URL erforderlich) ^{[license_location]}
E.g., as a top-level file named LICENSE or COPYING. License filenames MAY be followed by an extension such as ".txt" or ".md".

https://syncope.apache.org/license.html
Dokumentation

Criterion [documentation_basics]
Erfüllt

Unerfüllt

N/A

?

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.

https://syncope.apache.org/docs/getting-started.html https://syncope.apache.org/docs/reference-guide.html

Criterion [documentation_interface]
Erfüllt

Unerfüllt

N/A

?

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) oder 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.

https://syncope.apache.org/apidocs/2.0/index.html http://syncope.apache.org/rest/2.0/index.html
Andere

Criterion [sites_https]
Erfüllt

Unerfüllt

?

The project sites (website, repository, and download URLs) MUST support HTTPS using TLS. ^{[sites_https]}
You can get free certificates from Let's Encrypt. Projects MAY implement this criterion using (for example) GitHub pages, GitLab pages, or SourceForge project pages. If you are using GitHub pages with custom domains, you MAY use a content delivery network (CDN) as a proxy to support HTTPS, such as described in the blog post "Secure and fast GitHub Pages with CloudFlare", to satisfy this criterion. If you support HTTP, we urge you to redirect the HTTP traffic to HTTPS.

All website URLs are available as HTTP and HTTPS: http://syncope.apache.org/ -> https://syncope.apache.org/

Criterion [discussion]
Erfüllt

Unerfüllt

?

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.

User and developers mailing lists, IRC channel: https://syncope.apache.org/mailing-lists.html

Criterion [english]
Erfüllt

Unerfüllt

?

The project SHOULD provide documentation in English and be able to accept bug reports and comments about code in English. ^[english]
English is currently the lingua franca of computer technology; supporting English increases the number of different potential developers and reviewers worldwide. A project can meet this criterion even if its core developers' primary language is not English.

https://syncope.apache.org/docs/

(Fortgeschritten) Deaktiviere Inaktivitätserinnerung (wir empfehlen Ihnen, diese unausgewählt zu lassen)

Andere allgemeine Hinweise zum Projekt?

Verbesserungs/Nacharbeits -Kontrolle 9/9 ●

Öffentliches Versionskontroll Source Repository

Criterion [repo_public]
Erfüllt

Unerfüllt

?

The project MUST have a version-controlled source repository that is publicly readable and has a URL. ^{[repo_public]}
The URL MAY be the same as the project URL. The project MAY use private (non-public) branches in specific cases while the change is not publicly released (e.g., for fixing a vulnerability before it is revealed to the public).

https://git-wip-us.apache.org/repos/asf/syncope.git

This GIT repo is mirrored at GitHub under https://github.com/apache/syncope and we are able to manage PR from there.

Criterion [repo_track]
Erfüllt

Unerfüllt

?

The project's source repository MUST track what changes were made, who made the changes, and when the changes were made. ^[repo_track]

We use git.

Criterion [repo_interim]
Erfüllt

Unerfüllt

?

To enable collaborative review, the project's source repository MUST include interim versions for review between releases; it MUST NOT include only final releases. ^{[repo_interim]}
Projects MAY choose to omit specific interim versions from their public source repositories (e.g., ones that fix specific non-public security vulnerabilities, may never be publicly released, or include material that cannot be legally posted and are not in the final release).

Criterion [repo_distributed]
Erfüllt

Unerfüllt

?

It is SUGGESTED that common distributed version control software be used (e.g., git) for the project's source repository. ^{[repo_distributed]}
Git is not specifically required and projects can use centralized version control software (such as subversion) with justification.

We use git.
Einzigartige Versionsnummerierung

Criterion [version_unique]
Erfüllt

Unerfüllt

?

Die für Endbenutzer vorgesehenen Projektergebnisse MÜSSEN eine eindeutige Versionskennung für jede Freigabe haben. ^{[version_unique]}
This MAY be met in a variety of ways including a commit IDs (such as git commit id or mercurial changeset id) or a version number (including version numbers that use semantic versioning or date-based schemes like YYYYMMDD).

Criterion [version_semver]
Erfüllt

Unerfüllt

?

It is SUGGESTED that the Semantic Versioning (SemVer) format be used for releases. ^{[version_semver]}
Other version numbering schemes, such as commit IDs (such as git commit id or mercurial changeset id) or date-based schemes like YYYYMMDD, MAY be used as version numbers, since they are unique. Some alternatives can cause problems, because users may not be able to easily determine if they are up-to-date. SemVer may be less helpful for identifying software releases if all recipients only run the latest version (e.g., it is the code for a single website or internet service that is constantly updated via continuous delivery).

Criterion [version_tags]
Erfüllt

Unerfüllt

?

It is SUGGESTED that projects identify each release within their version control system. For example, it is SUGGESTED that those using git identify each release using git tags. ^{[version_tags]}
Versionshinweise

Criterion [release_notes]
Erfüllt

Unerfüllt

N/A

?

The project MUST provide, in each release, release notes that are a human-readable summary of major changes in that release to help users determine if they should upgrade and what the upgrade impact will be. The release notes MUST NOT be the raw output of a version control log (e.g., the "git log" command results are not release notes). Projects whose results are not intended for reuse in multiple locations (such as the software for a single website or service) AND employ continuous delivery MAY select "N/A". (URL erforderlich) ^{[release_notes]}
The release notes MAY be implemented in a variety of ways. Many projects provide them in a file named "NEWS", "CHANGELOG", or "ChangeLog", optionally with extensions such as ".txt", ".md", or ".html". Historically the term "change log" meant a log of every change, but to meet these criteria what is needed is a human-readable summary. The release notes MAY instead be provided by version control system mechanisms such as the GitHub Releases workflow.

https://cwiki.apache.org/confluence/display/SYNCOPE/Releases

Criterion [release_notes_vulns]
Erfüllt

Unerfüllt

N/A

?

The release notes MUST identify every publicly known vulnerability that is fixed in each new release. This is "N/A" if there are no release notes or there have been no publicly known vulnerabilities. ^{[release_notes_vulns]}

https://syncope.apache.org/security.html

Berichterstattung 8/8 ●

Bug-Report Prozess

Criterion [report_process]
Erfüllt

Unerfüllt

?

The project MUST provide a process for users to submit bug reports (e.g., using an issue tracker or a mailing list). (URL erforderlich) ^{[report_process]}

https://syncope.apache.org/contributing.html#How_to_contribute

Criterion [report_tracker]
Erfüllt

Unerfüllt

?

The project SHOULD use an issue tracker for tracking individual issues. ^{[report_tracker]}

https://issues.apache.org/jira/browse/SYNCOPE

Criterion [report_responses]
Erfüllt

Unerfüllt

?

The project MUST acknowledge a majority of bug reports submitted in the last 2-12 months (inclusive); the response need not include a fix. ^{[report_responses]}

Criterion [enhancement_responses]
Erfüllt

Unerfüllt

?

The project SHOULD respond to a majority (>50%) of enhancement requests in the last 2-12 months (inclusive). ^{[enhancement_responses]}
The response MAY be 'no' or a discussion about its merits. The goal is simply that there be some response to some requests, which indicates that the project is still alive. For purposes of this criterion, projects need not count fake requests (e.g., from spammers or automated systems). If a project is no longer making enhancements, please select "unmet" and include the URL that makes this situation clear to users. If a project tends to be overwhelmed by the number of enhancement requests, please select "unmet" and explain.

Criterion [report_archive]
Erfüllt

Unerfüllt

?

The project MUST have a publicly available archive for reports and responses for later searching. (URL erforderlich) ^{[report_archive]}

https://issues.apache.org/jira/browse/SYNCOPE
Anfälligkeits-Prozessbericht

Criterion [vulnerability_report_process]
Erfüllt

Unerfüllt

?

Das Projekt MUSS den Prozess für die Meldung von Schwachstellen auf der Projektseite veröffentlichen. (URL erforderlich) ^{[vulnerability_report_process]}
E.g., a clearly designated mailing address on https://PROJECTSITE/security, often in the form security@example.org. This MAY be the same as its bug reporting process. Vulnerability reports MAY always be public, but many projects have a private vulnerability reporting mechanism.

http://www.apache.org/security/

Criterion [vulnerability_report_private]
Erfüllt

Unerfüllt

N/A

?

If private vulnerability reports are supported, the project MUST include how to send the information in a way that is kept private. (URL erforderlich) ^{[vulnerability_report_private]}
Examples include a private defect report submitted on the web using HTTPS (TLS) or an email encrypted using OpenPGP. If vulnerability reports are always public (so there are never private vulnerability reports), choose "not applicable" (N/A).

http://www.apache.org/security/#reporting-a-vulnerability

Criterion [vulnerability_report_response]
Erfüllt

Unerfüllt

N/A

?

The project's initial response time for any vulnerability report received in the last 6 months MUST be less than or equal to 14 days. ^{[vulnerability_report_response]}
Wenn in den letzten 6 Monaten keine Schwachstellen gemeldet wurden, wählen Sie "nicht anwendbar" (N/A).

Qualität 13/13 ●

Produktivsystem

Criterion [build]
Erfüllt

Unerfüllt

N/A

?

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).

We use Travis CI: https://travis-ci.org/apache/syncope

Criterion [build_common_tools]
Erfüllt

Unerfüllt

N/A

?

Es ist EMPFHOLEN, dass gewöhnliche Werkzeuge zum Kompiliren von Software benutzt wird. ^{[build_common_tools]}
Beispielsweise, Maven, Ant, cmake, die Autotools, make oder rake.

Criterion [build_floss_tools]
Erfüllt

Unerfüllt

N/A

?

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

The build process only requires Apache Maven.
Automatisierte Test-Suite

Criterion [test]
Erfüllt

Unerfüllt

?

The project MUST use at least one automated test suite that is publicly released as FLOSS (this test suite may be maintained as a separate FLOSS project). ^[test]
The project MAY use multiple automated test suites (e.g., one that runs quickly, vs. another that is more thorough but requires special equipment).

Unit and integration tests are part of the codebase and run at every build.

Criterion [test_invocation]
Erfüllt

Unerfüllt

?

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".

The Apache Maven Surefire and Failsafe plugin are used.

Criterion [test_most]
Erfüllt

Unerfüllt

?

It is SUGGESTED that the test suite cover most (or ideally all) the code branches, input fields, and functionality. ^[test_most]

Criterion [test_continuous_integration]
Erfüllt

Unerfüllt

?

It is SUGGESTED that the project implement continuous integration (where new or changed code is frequently integrated into a central code repository and automated tests are run on the result). ^{[test_continuous_integration]}

Travis CI builds are triggered by commits and PRs.
Neue Funktionalitäts-Überprüfung

Criterion [test_policy]
Erfüllt

Unerfüllt

?

The project MUST have a general policy (formal or not) that as major new functionality is added to the software produced by the project, tests of that functionality should be added to an automated test suite. ^{[test_policy]}
As long as a policy is in place, even by word of mouth, that says developers should add tests to the automated test suite for major new functionality, select "Met."

Criterion [tests_are_added]
Erfüllt

Unerfüllt

?

The project MUST have evidence that the test_policy for adding tests has been adhered to in the most recent major changes to the software produced by the project. ^{[tests_are_added]}
Major functionality would typically be mentioned in the release notes. Perfection is not required, merely evidence that tests are typically being added in practice to the automated test suite when new major functionality is added to the software produced by the project.

Criterion [tests_documented_added]
Erfüllt

Unerfüllt

?

It is SUGGESTED that this policy on adding tests (see test_policy) be documented in the instructions for change proposals. ^{[tests_documented_added]}
Allerdings ist auch eine informelle Regel akzeptabel, solange die Tests in der Praxis hinzugefügt werden.
Warnhinweise

Criterion [warnings]
Erfüllt

Unerfüllt

N/A

?

The project MUST enable one or more compiler warning flags, a "safe" language mode, or use a separate "linter" tool to look for code quality errors or common simple mistakes, if there is at least one FLOSS tool that can implement this criterion in the selected language. ^[warnings]
Examples of compiler warning flags include gcc/clang "-Wall". Examples of a "safe" language mode include JavaScript "use strict" and perl5's "use warnings". A separate "linter" tool is simply a tool that examines the source code to look for code quality errors or common simple mistakes. These are typically enabled within the source code or build instructions.

The build process enforces code quality checks via Checkstyle and Apache RAT plugins.

Criterion [warnings_fixed]
Erfüllt

Unerfüllt

N/A

?

Das Projekt MUSS auf Warnungen reagieren. ^{[warnings_fixed]}
These are the warnings identified by the implementation of the warnings criterion. The project should fix warnings or mark them in the source code as false positives. Ideally there would be no warnings, but a project MAY accept some warnings (typically less than 1 warning per 100 lines or less than 10 warnings).

Criterion [warnings_strict]
Erfüllt

Unerfüllt

N/A

?

It is SUGGESTED that projects be maximally strict with warnings in the software produced by the project, where practical. ^{[warnings_strict]}
Some warnings cannot be effectively enabled on some projects. What is needed is evidence that the project is striving to enable warning flags where it can, so that errors are detected early.

Sicherheit 16/16 ●

Wissen über sichere Entwicklungspraktiken
Criterion [know_secure_design]
Erfüllt

Unerfüllt

?
The project MUST have at least one primary developer who knows how to design secure software. ^{[know_secure_design]}
This requires understanding the following design principles, including the 8 principles from Saltzer and Schroeder:
- economy of mechanism (keep the design as simple and small as practical, e.g., by adopting sweeping simplifications)
- fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default)
- complete mediation (every access that might be limited must be checked for authority and be non-bypassable)
- open design (security mechanisms should not depend on attacker ignorance of its design, but instead on more easily protected and changed information like keys and passwords)
- separation of privilege (ideally, access to important objects should depend on more than one condition, so that defeating one protection system won't enable complete access. E.G., multi-factor authentication, such as requiring both a password and a hardware token, is stronger than single-factor authentication)
- least privilege (processes should operate with the least privilege necessary)
- least common mechanism (the design should minimize the mechanisms common to more than one user and depended on by all users, e.g., directories for temporary files)
- psychological acceptability (the human interface must be designed for ease of use - designing for "least astonishment" can help)
- limited attack surface (the attack surface - the set of the different points where an attacker can try to enter or extract data - should be limited)
- input validation with whitelists (inputs should typically be checked to determine if they are valid before they are accepted; this validation should use whitelists (which only accept known-good values), not blacklists (which attempt to list known-bad values)).
A "primary developer" in a project is anyone who is familiar with the project's code base, is comfortable making changes to it, and is acknowledged as such by most other participants in the project. A primary developer would typically make a number of contributions over the past year (via code, documentation, or answering questions). Developers would typically be considered primary developers if they initiated the project (and have not left the project more than three years ago), have the option of receiving information on a private vulnerability reporting channel (if there is one), can accept commits on behalf of the project, or perform final releases of the project software. If there is only one developer, that individual is the primary developer.
Criterion [know_common_errors]
Erfüllt

Unerfüllt

?

At least one of the project's primary developers MUST know of common kinds of errors that lead to vulnerabilities in this kind of software, as well as at least one method to counter or mitigate each of them. ^{[know_common_errors]}
Examples (depending on the type of software) include SQL injection, OS injection, classic buffer overflow, cross-site scripting, missing authentication, and missing authorization. See the CWE/SANS top 25 or OWASP Top 10 for commonly used lists.
Verwende grundlegend gute kryptographische Praktiken
Beachte, dass einige Software keine kryptographischen Mechanismen verwenden muss.

Criterion [crypto_published]
Erfüllt

Unerfüllt

N/A

?

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.

Criterion [crypto_call]
Erfüllt

Unerfüllt

N/A

?

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]}

Criterion [crypto_floss]
Erfüllt

Unerfüllt

N/A

?

Alle Funktionalitäten in der vom Projekt entwickelten Software, die von Kryptographie abhängigen, MÜSSEN mit FLOSS implementiert werden. ^{[crypto_floss]}
Siehe Open Standards Requirement for Software by the Open Source Initiative.

Criterion [crypto_keylength]
Erfüllt

Unerfüllt

N/A

?

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).

Criterion [crypto_working]
Erfüllt

Unerfüllt

N/A

?

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 (z.B. EZB-Modus ist fast nie geeignet, weil es identische Blöcke innerhalb des Chiffretextes enthüllt, wie durch den EZB-Pinguin gezeigt wird und der CTR-Modus ist oft unangemessen, weil es keine Authentifizierung durchführt und Duplikate verursacht, wenn der Eingangszustand wiederholt wird). ^{[crypto_working]}
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, falls nötig für Kompatibilität, aber dann wissen die Benutzer, dass sie es tun.

Criterion [crypto_weaknesses]
Erfüllt

Unerfüllt

N/A

?

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.

Criterion [crypto_pfs]
Erfüllt

Unerfüllt

N/A

?

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]

Criterion [crypto_password_storage]
Erfüllt

Unerfüllt

N/A

?

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.

Criterion [crypto_random]
Erfüllt

Unerfüllt

N/A

?

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.
Gesicherte Zustellung gegen Man-in-the-Middle (MITM) Angriffe

Criterion [delivery_mitm]
Erfüllt

Unerfüllt

?

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.

Criterion [delivery_unsigned]
Erfüllt

Unerfüllt

?

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.
Öffentlich bekannte Schwachstellen wurden behoben

Criterion [vulnerabilities_fixed_60_days]
Erfüllt

Unerfüllt

?

There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days. ^{[vulnerabilities_fixed_60_days]}
The vulnerability must be patched and released by the project itself (patches may be developed elsewhere). A vulnerability becomes publicly known (for this purpose) once it has a CVE with publicly released non-paywalled information (reported, for example, in the National Vulnerability Database) or when the project has been informed and the information has been released to the public (possibly by the project). A vulnerability is medium to high severity if its CVSS 2.0 base score is 4 or higher. Note: this means that users might be left vulnerable to all attackers worldwide for up to 60 days. This criterion is often much easier to meet than what Google recommends in Rebooting responsible disclosure, because Google recommends that the 60-day period start when the project is notified even if the report is not public.

Criterion [vulnerabilities_critical_fixed]
Erfüllt

Unerfüllt

?

Projekte SOLLTEN alle kritischen Schwachstellen schnell nachdem sie gemeldet wurden beheben. ^{[vulnerabilities_critical_fixed]}
Andere Sicherheitsissues

Criterion [no_leaked_credentials]
Erfüllt

Unerfüllt

?

The public repositories MUST NOT leak a valid private credential (e.g., a working password or private key) that is intended to limit public access. ^{[no_leaked_credentials]}
A project MAY leak "sample" credentials for testing and unimportant databases, as long as they are not intended to limit public access.

Analyse 7/8 ●

Statische Codeanalyse

Criterion [static_analysis]
Erfüllt

Unerfüllt

N/A

?

At least one static code analysis tool MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language. ^{[static_analysis]}
A static code analysis tool examines the software code (as source code, intermediate code, or executable) without executing it with specific inputs. For purposes of this criterion, compiler warnings and "safe" language modes do not count as static code analysis tools (these typically avoid deep analysis because speed is vital). Examples of such static code analysis tools include cppcheck, clang static analyzer, FindBugs (including FindSecurityBugs), PMD, Brakeman, Coverity Quality Analyzer, and HP Fortify Static Code Analyzer. Larger lists of tools can be found in places such as the Wikipedia list of tools for static code analysis, OWASP information on static code analysis, NIST list of source code security analyzers, and Wheeler's list of static analysis tools. The SWAMP is a no-cost platform for assessing vulnerabilities in software using a variety of tools. If there are no FLOSS static analysis tools available for the implementation language(s) used, select 'N/A'.

Warnung: Erfordert eine längere Begründung.

Criterion [static_analysis_common_vulnerabilities]
Erfüllt

Unerfüllt

N/A

?

It is SUGGESTED that at least one of the static analysis tools used for the static_analysis criterion include rules or approaches to look for common vulnerabilities in the analyzed language or environment. ^{[static_analysis_common_vulnerabilities]}

Criterion [static_analysis_fixed]
Erfüllt

Unerfüllt

N/A

?

All medium and high severity exploitable vulnerabilities discovered with static code analysis MUST be fixed in a timely way after they are confirmed. ^{[static_analysis_fixed]}
A vulnerability is medium to high severity if its CVSS 2.0 is 4 or higher.

Criterion [static_analysis_often]
Erfüllt

Unerfüllt

N/A

?

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

Criterion [dynamic_analysis]
Erfüllt

Unerfüllt

?

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]}
A dynamic analysis tool examines the software by executing it with specific inputs. For example, the project MAY use a fuzzing tool (e.g., American Fuzzy Lop) or a web application scanner (e.g., OWASP ZAP or w3af). In some cases the OSS-Fuzz project may be willing to apply fuzz testing to your project. For purposes of this criterion the dynamic analysis tool needs to vary the inputs in some way to look for various kinds of problems or be an automated test suite with at least 80% branch coverage. The Wikipedia page on dynamic analysis and the OWASP page on fuzzing identify some dynamic analysis tools. The analysis tool(s) MAY be focused on looking for security vulnerabilities, but this is not required.

Criterion [dynamic_analysis_unsafe]
Erfüllt

Unerfüllt

N/A

?

It is SUGGESTED that if the software produced by the project includes software written using a memory-unsafe language (e.g., C or C++), then at least one dynamic tool (e.g., a fuzzer or web application scanner) be routinely used in combination with a mechanism to detect memory safety problems such as buffer overwrites. If the project does not produce software written in a memory-unsafe language, choose "not applicable" (N/A). ^{[dynamic_analysis_unsafe]}
Examples of mechanisms to detect memory safety problems include Address Sanitizer (ASAN) (available in GCC and LLVM), Memory Sanitizer, and valgrind. Other potentially-used tools include thread sanitizer and undefined behavior sanitizer. Widespread assertions would also work.

Criterion [dynamic_analysis_enable_assertions]
Erfüllt

Unerfüllt

?

It is SUGGESTED that the software produced by the project include many run-time assertions that are checked during dynamic analysis. ^{[dynamic_analysis_enable_assertions]}

Criterion [dynamic_analysis_fixed]
Erfüllt

Unerfüllt

N/A

?

All medium and high severity exploitable vulnerabilities discovered with dynamic code analysis MUST be fixed in a timely way after they are confirmed. ^{[dynamic_analysis_fixed]}
A vulnerability is medium to high severity if its CVSS 2.0 base score is 4. If you are not running dynamic code analysis and thus have not found any vulnerabilities in this way, choose "not applicable" (N/A).

Zukunft 8/8 ●

These are criteria we intend to add in the near future, but are not currently required for a badge. This grace period allows projects to update to changed criteria and retain their badge as best practices improve.

Criterion [installation_common]

Erfüllt

Unerfüllt

(Zukünftiges Kriterium) The project SHOULD provide a way to easily install and uninstall the software produced by the project using a commonly-used convention. ^{[installation_common]}

Examples include using a package manager (at the system or language level), "make install/uninstall" (supporting DESTDIR), a container in a standard format, or a virtual machine image in a standard format. The installation and uninstallation process (e.g., its packaging) MAY be implemented by a third party as long as it is FLOSS.

Besides Apache Maven-based project generation via archetype, we also provide a GUI installer and a standalone distribution ZIP archive.

Criterion [build_reproducible]

Erfüllt

Unerfüllt

N/A

(Zukünftiges Kriterium) Es ist EMPFHOLEN, dass das Projekt Reproduzierbare Builds hat. Wenn kein Build nötig ist (z.B. bei Skriptsprachen deren Quellcode direkt verwendet wird, anstatt kompiliert zu werden), wählen Sie "N/A". ^{[build_reproducible]}

Eine reproduzierbares Build bedeutet, dass mehrere Parteien den Prozess der Generierung von Informationen aus Quelldateien unabhängig voneinander wiederholen und genau das gleiche Bit-für-Bit-Ergebnis erhalten können. In manchen Fällen kann dies dadurch gelöst werden, dass man eine Sortierreihenfolge erzwingt. JavaScript-Entwickler können erwägen npm shrinkwrap und webpack OccurenceOrderPlugin zu verwenden. GCC und clang Benutzer können die Option -frandom-seed nützlich finden. Die Buildumgebung (einschließlich des Toolsets) kann oft für externe Teilnehmer definiert werden, indem der kryptografische Hash eines bestimmten Containers oder einer virtuellen Maschine angegeben wird, die sie für den Wiederaufbau verwenden können. Das Reproducible Builds Projekt hat eine Dokumentation, wie dies erreicht werden kann.

Criterion [crypto_used_network]

Erfüllt

Unerfüllt

N/A

(Zukünftiges Kriterium) Die vom Projekt entwickelte Software SOLLTE sichere Protokolle für alle Netzwerkkommunikationen wie SSHv2 oder neuer, TLS1.2 oder neuer (HTTPS), IPsec, SFTP und SNMPv3 unterstützen. Unsichere Protokolle wie FTP, HTTP, Telnet, SSLv3 oder älter, und SSHv1 sollte standardmäßig deaktiviert werden und nur aktiviert werden, wenn der Benutzer es speziell konfiguriert. Wenn die vom Projekt entwickelte Software keine Netzwerkkommunikation unterstützt, wählen Sie "nicht anwendbar" (N/A). ^{[crypto_used_network]}

Criterion [crypto_tls12]

Erfüllt

Unerfüllt

N/A

(Zukünftiges Kriterium) Die vom Projekt entwickelte Software SOLLTE, wenn sie TLS unterstützt oder verwendet, mindestens TLS Version 1.2 unterstützen. Beachten Sie, dass der Vorgänger von TLS SSL genannt wurde. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). ^{[crypto_tls12]}

Criterion [crypto_certificate_verification]

Erfüllt

Unerfüllt

N/A

(Zukünftiges Kriterium) Die Software, die vom Projekt produziert wird, MUSS, wenn sie TLS unterstützt, die TLS-Zertifikatprüfung standardmäßig durchführen wenn TLS verwendet wird, auch für Subresources, durchführen. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). ^{[crypto_certificate_verification]}

Beachten Sie, dass eine falsche TLS-Zertifikatsüberprüfung ein häufiger Fehler ist. Weitere Informationen finden Sie unter "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software" von Martin Georgiev et al. und "Do you trust this application?" von Michael Catanzaro.

Criterion [crypto_verification_private]

Erfüllt

Unerfüllt

N/A

(Zukünftiges Kriterium) Die vom Projekt entwickelte Software, SOLLTE, wenn sie TLS unterstützt, die TLS-Zertifikatprüfung standardmäßig durchführen wenn TLS verwendet wird, auch für Subresources, durchführen. Wenn die Software TLS nicht verwendet, wählen Sie "nicht anwendbar" (N/A). ^{[crypto_verification_private]}

Criterion [hardened_site]

Erfüllt

Unerfüllt

(Zukünftiges Kriterium) It is SUGGESTED that the project website, repository (if accessible via the web), and download site (if separate) include key hardening headers with nonpermissive values. ^{[hardened_site]}

Note that GitHub is known to meet this. Sites such as https://securityheaders.io/ can quickly check this. The key hardening headers are: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as "nosniff"), X-Frame-Options, and X-XSS-Protection.

Criterion [hardening]

Erfüllt

Unerfüllt

(Zukünftiges Kriterium) It is SUGGESTED that hardening mechanisms be used in the software produced by the project so that software defects are less likely to result in security vulnerabilities. ^[hardening]

Hardening mechanisms may include HTTP headers like Content Security Policy (CSP), compiler flags to mitigate attacks (such as -fstack-protector), or compiler flags to eliminate undefined behavior. For our purposes least privilege is not considered a hardening mechanism (least privilege is important, but separate).

This data is available under the Creative Commons Attribution version 3.0 license (CC-BY-3.0) per the Core Infrastructure Initiative terms of use. All are free to share and adapt the data, but must give appropriate credit. Please credit Francesco Chicchiriccò and the CII Best Practices badge contributors.

Apache Syncope

Grundlagen 12/12 ●

Identifizierung

Basic project website content

FLOSS License

Dokumentation

Andere

Verbesserungs/Nacharbeits -Kontrolle 9/9 ●

Öffentliches Versionskontroll Source Repository

Einzigartige Versionsnummerierung

Versionshinweise

Berichterstattung 8/8 ●

Bug-Report Prozess

Anfälligkeits-Prozessbericht

Qualität 13/13 ●

Produktivsystem

Automatisierte Test-Suite

Neue Funktionalitäts-Überprüfung

Warnhinweise

Sicherheit 16/16 ●

Wissen über sichere Entwicklungspraktiken

Verwende grundlegend gute kryptographische Praktiken

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

Öffentlich bekannte Schwachstellen wurden behoben

Andere Sicherheitsissues

Analyse 7/8 ●

Statische Codeanalyse

Dynamische Codeanalyse

Zukunft 8/8 ●