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?

OPNFV is a carrier-grade, integrated, open source platform to accelerate the introduction of new network functions virtualization (NFV) products and services. As an open source project, OPNFV is uniquely positioned to bring together the work of standards bodies, open source communities and commercial suppliers to deliver a de facto standard open source NFV platform for the industry. Participation is open to anyone, whether you are an employee of a member company or just passionate about network transformation.

Andere

This requires that the project home page URL and the version control repository URL begin with "https:", not "http:". 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.

(Advanced) What other users have additional rights to edit this badge entry? Currently: []

Most projects should ignore this field. Project badge entries can always be edited by the badge entry owner (creator), BadgeApp administrators, and anyone who can commit to the GitHub repository (if it's on GitHub). If you want someone else to be able to edit this badge entry, and you already have edit rights to this project badge entry, you can additional users with edit rights. Just enter "+" followed by a comma-separated list of integer user ids. Those users will then also be allowed to edit this project entry. If you're the owner of the badge entry or a BadgeApp administrator, you can remove users from this list by entering "-" followed by a comma-separated list of integer user ids. We expect that normally only one person will edit a particular badge entry at a time. This application uses optimistic locking to prevent saving stale data if multiple users try to edit a badge entry simultaneously. If you have multiple editors, we recommend saving badge entry data incrementally and often (that is a wise practice anyway).

Andere allgemeine Hinweise zum Projekt?

Verbesserungs/Nacharbeits -Kontrolle
9/9●

Öffentliches Versionskontroll Source Repository

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

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

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.

Einzigartige Versionsnummerierung

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

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.

The release notes MUST identify every publicly known vulnerability with a CVE assignment or similar that is fixed in each new release, unless users typically cannot practically update the software themselves. If there are no release notes or there have been no publicly known vulnerabilities, choose "not applicable" (N/A).
[release_notes_vulns]

If users typically cannot practically update the software themselves on their computers, but must instead depend on a middleman to perform the upgrade (as is often the case for a kernel and low-level software that is intertwined with a kernel), the project may choose "not applicable" (N/A).

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.

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

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

OPNFV project run automated functional test on all code committed.

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]

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

OPNFV project run automated functional test on all code committed.

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.

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.

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.

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.

Andere Sicherheitsissues

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
8/8●

Statische Codeanalyse

Criterion [static_analysis]

Erfüllt

Unerfüllt

N/A

?

At least one static code analysis tool (beyond compiler warnings and "safe" language modes) 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]

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]

Static analysis tools that are specifically designed to look for common vulnerabilities are more likely to find them. That said, using any static tools will typically help find some problems, so we are suggesting but not requiring this for the 'passing' level badge.

OPNFV , consists of many projects with different levels of scope. Some are specification based, some are unit / black box testing, and others intend to contribute upstream to other OSS projects (such as OpenStack), therefore it is challenging to find a common and useful approach to static / dynamic analysis that fits all. With this in mind, the Security Group will work with the different OPNFV projects to assess their threat exposure, and what they can do to insure a secure code base. If suited we will make recommendations on scanning solutions available.

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.

The OPNFV project's intention is to fix all exploitable vulnerabilities in a timely way after they are confirmed.

OPNFV , consists of many projects with different levels of scope. Some are specification based, some are unit / black box testing, and others intend to contribute upstream to other OSS projects (such as OpenStack), therefore it is challenging to find a common and useful approach to static / dynamic analysis that fits all. With this in mind, the Security Group will work with the different OPNFV projects to assess their threat exposure, and what they can do to insure a secure code base. If suited we will make recommendations on scanning solutions available.