Page History

...

3.1 ONAP Static Code Scanning

The purpose of the ONAP static code scanning is perform static code scans of the code as it is introduced into the ONAP repositories looking for vulnerabilities.

3.2 Approaches

Tools that have been assessed: Coverity Scan (LF evaluation), HP Fortify (AT&T evaluation), Checkmarx (AT&T evaluation), Bandit (AT&T evaluation)

...

• Level 1 70% of the projects included in the release at passing badge level
• with non-passing projects reaching 80% towards passing level.
• Non passing projects MUST pass these specific criteria
• <insert top 3 here>
candidates to include are
• :
• The project MUST have a public website with a stable URL. (The badging application enforces this by requiring a URL to create a badge entry.)
• The project website MUST succinctly describe what the software does       (what problem does it solve?).
• The software produced by the project MUST be released as FLOSS.
• The  project MUST post the license(s) of its results in a standard location in       their source repository. (URL required for "met".)
• The project MUST provide basic documentation for the software       produced by the project.
• The project MUST provide reference documentation       that describes the external interface (both input and output) of the       software produced by the project.
• The project MUST       have a version-controlled source repository that is publicly readable and       has a URL.
The       project results MUST have a unique version identifier for each release       intended to be used by users.
• • 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.       (N/A allowed.) (Justification required for "N/A".)If the
• • software
     
• • produced by
the project requires building for use,
• • the project MUST
      provide a working build system that can automatically rebuild the       software from source code.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. (N/A       allowed.)
• The project MUST have at least one primary developer who knows how to       design secure software.
• 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.
The       software produced
• • by
the project MUST use, by
• • default, only
cryptographic       protocols
• • cryptographic protocols and algorithms that are publicly published and reviewed by
     
• • experts (if cryptographic protocols and algorithms are used).
  • If
the       software
• • the software produced by the project is an application or library, and its
     
• • primary purpose is not to implement cryptography, then it SHOULD only       call on software specifically designed to implement cryptographic
     
• • functions; it SHOULD NOT re-implement its own.
  • The
     
• • security mechanisms within the software produced by the project MUST use       default keylengths that at least meet the NIST minimum requirements       through the year 2030 (as stated in 2012). It MUST be possible to       configure the software so that smaller keylengths are completely       disabled.
  • The
     
• • default security mechanisms within the software produced by the project       MUST NOT depend on broken cryptographic algorithms (e.g., MD4, MD5,       single DES, RC4, Dual_EC_DRBG) or use cipher modes that are inappropriate       to the context (e.g., ECB mode is almost never appropriate because it       reveals identical blocks within the ciphertext as demonstrated by the ECB penguin, and
CTR      
• • CTR  mode is often inappropriate because it does not perform authentication       and causes duplicates if the input state is repeated).
  • The
     
• • default security mechanisms within the software produced by the project       SHOULD NOT depend on cryptographic algorithms or modes with known serious       weaknesses (e.g., the SHA-1 cryptographic hash algorithm or the CBC mode
     
• • in SSH).
  • If the software produced by the project causes the storing of       passwords for authentication of external users, the passwords MUST be       stored as iterated hashes with a per-user salt by using a key stretching       (iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt)
.The       security mechanisms within the software produced by the project MUST       generate all cryptographic keys and nonces using a cryptographically       secure random number generator, and MUST NOT do so using generators that       are cryptographically insecure
• • .
• There MUST be no unpatched vulnerabilities of       medium or high severity that have been publicly known for more than 60       days.
• Projects SHOULD fix all critical vulnerabilities       rapidly after they are reported.
• 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.
• 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.
• All medium and high severity exploitable vulnerabilities discovered       with static code analysis MUST be fixed in a timely way after they are       confirmed.
• It is       SUGGESTED that at least one dynamic analysis tool be applied to any       proposed major production release of the software before its release.
All medium and high severity exploitable vulnerabilities discovered       with dynamic code analysis MUST be fixed in a timely way after they are       confirmed. (N/A allowed.)
• Level 2  70% of the projects in the release passing silver
  • with non-silver projects completed passing level and 80% towards silver level
• Level 3 70% of the projects included in the release passing gold
  • with non-gold projects achieving silver level and achieving 80% towards gold level
• Level 4: 100% of the projects in the release passing gold level. 

...