This requires understanding secure 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).

This document highlights a core set of high-level secure software development practices: 

• Secure Software Development Framework
• Please review the “Produce Well-Secured Software” section.  Suggests using forms of risk modeling for assessing the security risk and using standardized security features and services for implementations.

_{[know_secure_design P]}

The project must implement secure design principles (from 'know secure design').

For example, the project results should have fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default). They should also have complete mediation (every access that might be limited must be checked for authority and be non-bypassable). Note that in some cases principles will conflict, in which case a choice must be made (e.g., many mechanisms can make things more complex, contravening 'economy of mechanism' / keep it simple).

Implement secure design builds on the question above of "know secure design". For ONAP, the committers must all know the secure design principles and reviewing the code must always includes looking at it from the point of review of the security principles.

It's crucial to document the secure design practices and software design/coding standards and code review. This NIST SSDF document provides additional details: 

• Secure Software Development Framework

_{[implement_secure_design S]}

Examples of common kinds of errors that lead to vulnerabilities in this kind 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. Many books and courses are available to help you understand how to develop more secure software and discuss common implementation errors that lead to vulnerabilities. For example, the Secure Software Development Fundamentals course is a free set of three courses that explain how to develop more secure software (it's free if you audit it; for an extra fee you can earn a certificate to prove you learned the material).

_{[know_common_errors P]}

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.
A project MAY leak 'sample' credentials for testing and unimportant databases, as long as they are not intended to limit public access.

_{[no_leaked_credentials P]}

A software architecture explains a program's fundamental structures, i.e., the program's major components, the relationships among them, and the key properties of these components and relationships.

The architecture would often be part of the documents that describe what the software does and its interfaces.

_{[documentation_architecture S]}

These are the security requirements that the software is intended to meet.

There needs to be:

• a description of the threat model,
• clear identification of trust boundaries,
• how the software expects to deal with the threat model and trust boundaries

_{[documentation_security S]}

For ONAP, somewhere in the project's description, there needs to be (as indicated above):

• a description of how the project met the threat model,
• a description of how the project maintains the trust boundaries,
• an argument that secure design principles have been applied, and
• an argument that common implementation security weaknesses have been countered.

This may be combined with the "documentation security" document.

_{[assurance_case S]}

All critical vulnerabilities should be fixed rapidly after they are reported.

_{[vulnerabilities_critical_fixed P]}

There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 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 considered medium or higher severity if its Common Vulnerability Scoring System (CVSS) base qualitative score is medium or higher. In CVSS versions 2.0 through 3.1, this is equivalent to a CVSS score of 4.0 or higher. Projects may use the CVSS score as published in a widely-used vulnerability database (such as the National Vulnerability Database) using the most-recent version of CVSS reported in that database. Projects may instead calculate the severity themselves using the latest version of CVSS at the time of the vulnerability disclosure, if the calculation inputs are publicly revealed once the vulnerability is publicly known. 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. Also note that this applies to each individual project in ONAP. Once a patch is available from each individual project, others can determine how to deal with the patch (e.g., they can update to the newer version or they can apply just the patch as a cherry-picked solution).

_{[vulnerabilities_fixed_60_days P]}

The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (an *allowlist*), and reject invalid inputs, if there are any restrictions on the data at all.
Note that comparing input against a list of 'bad formats' (aka a *denylist*) is normally not enough, because attackers can often work around a denylist. In particular, numbers are converted into internal formats and then checked if they are between their minimum and maximum (inclusive), and text strings are checked to ensure that they are valid text patterns (e.g., valid UTF-8, length, syntax, etc.). Some data may need to be 'anything at all' (e.g., a file uploader), but these would typically be rare.

_{[input_validation S]}

If you compile code into binary executables, do you use

• compiler flags to mitigate attacks (such as -fstack-protector)?
• compiler flags to eliminate undefined behavior?
• special build features like Address Sanitizer (ASAN) (if available)?

If your project provides a web user interface:

• Does it require the hardening headers: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as 'nosniff'), and X-Frame-Options?
• If your web site were to be passed to a website such as <securityheaders.com>, would you get a grade of A or B?
• Are administrative web pages shown or listed only if the logged in user is an administrator?
• Are your JavaScript and CSS served from separate files?
• Do you use HTTP to HTTPS redirects?
• Do you use HSTS?
• If appropriated, do you do rate limiting to prevent DOS attacks?
• Do you employ measures to resist Cross Site Request Forgeries (CSRFs)?
• Do your cookies use settings to counter Javascript-based attacks, set secure=true, and counter CSRF using a SameSite value?
• Do you protect use of target='_blank' with rel="noopener noreferrer"?

If your project generates email:

• Do you take measures for rate limiting?
• Do you encrypt the email addresses that might be stored in a database?

If your project uses a database:

• Do you encrypt values that are sensitive?

_{[hardening SG]}

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

_{[crypto_call P]}

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.

A cryptographically secure random number generator may be a hardware random number generator (/dev/random), or it may be a cryptographically secure pseudo-random number generator (CSPRNG) using an algorithm such as Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow, or Fortuna. Examples of calls to secure random number generators include Java's java.security.SecureRandom and JavaScript's window.crypto.getRandomValues. Examples of calls to insecure random number generators include Java's java.util.Random and JavaScript's Math.random.

For additional guidance and examples about what kind of specifications to rate a random bit generator (RBG) please review: 

• NIST 800-90C explains putting various pieces together (entropy source and the "pseudo-random number generator" PRNG) - Recommendation for Random Bit Generator (RBG) Constructions.
• NIST 800-90A references the PRNG algorithms - Recommendation for Random Number Generation Using Deterministic Random Bit Generators.
• NIST 800-90B references testing requirements for entropy sources - Recommendation for the Entropy Sources Used for Random Bit Generation.

_{[crypto_random P]}

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 algorithms, or the CBC mode in SSH).
Concerns about CBC mode in SSH are discussed in CERT: SSH CBC vulnerability.

_{[crypto_weaknesses PS]}

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, unless they are necessary to implement an interoperable protocol (where the protocol implemented is the most recent version of that standard broadly supported by the network ecosystem, that ecosystem requires the use of such an algorithm or mode, and that ecosystem does not offer any more secure alternative). The documentation MUST describe any relevant security risks and any known mitigations if these broken algorithms or modes are necessary for an interoperable protocol.
ECB mode is almost never appropriate because it reveals identical blocks within the ciphertext as demonstrated by the ECB Penguin, and CTR mode is often inappropriate because it does not perform authentication and causes duplicates if the input state is repeated. In many cases it's best to choose a block cipher algorithm mode designed to combine secrecy and authentication, e.g., Galois/Counter Mode (GCM) and EAX. Projects MAY allow users to enable broken mechanisms (e.g., during configuration) where necessary for compatibility, but then users know they're doing it.

_{[crypto_working P]}

The security mechanisms within the software produced by the project MUST use default key-lengths 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 key-lengths are completely disabled.
These minimum bit-lengths are: symmetric key 112, factoring modulus 2048, discrete logarithm key 224, discrete logarithmic group 2048, elliptic curve 224, and hash 224 (password hashing is not covered by this bit-length, more information on password hashing can be found in the Crypto Password Storage question). See <www.keylength.com> for a comparison of key-length recommendations from various organizations. The software MAY allow smaller key-lengths in some configurations (ideally it would not, since this allows downgrade attacks, but shorter key-lengths are sometimes necessary for interoperability).

_{[crypto_keylength P]}

The project SHOULD support multiple cryptographic algorithms, so users can quickly switch if one is broken. Common symmetric key algorithms include AES, Twofish, and Serpent. Common cryptographic hash algorithm alternatives include SHA-2 (including SHA-224, SHA-256, SHA-384 AND SHA-512) and SHA-3.

_{[crypto_algorithm_agility S]}

This applies to both ingress into and egress from your project.

• For ingress, this applies to validation of the client certificates coming into your system.
• For egress, this applies to validation of the host certificates for external systems that your system reads from or sends to.

The software produced by the project MUST, if it supports TLS, perform TLS certificate verification by default when using TLS, including on sub-resources.
Note that incorrect TLS certificate verification is a common mistake. For more information, see The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software by Martin Georgiev et al. and Do you trust this application? by Michael Catanzaro.

Note: One aspect of this is that, if something is missing that prevents the TLS from working, the software must NOT fall back to insecure mode but must instead prevent communication. If an insecure mode is allowed, it MUST be explicitly configured.

Note 2: If all of your traffic, either ingress or egress, is travelling through the ONAP mesh, then make a statement about that.

_{[crypto_certificate_verification S]}

The project MUST support storing authentication credentials (such as passwords and dynamic tokens) and private cryptographic keys in files that are separate from other information (such as configuration files, databases, and logs), and permit users to update and replace them without code recompilation.

_{[crypto_credential_agility S]}

The software produced by the project MUST, if it supports or uses TLS, support at least TLS version 1.2. Note that the predecessor of TLS was called SSL.

_{[crypto_tls12 SG]}

The software produced by the project MUST support secure protocols for all of its network communications, such as SSHv2 or later, TLS1.2 or later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP, HTTP, telnet, SSLv3 or earlier, and SSHv1 MUST be disabled by default, and only enabled if the user specifically configures it.

_{[crypto_used_network SG]}

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies).

_{[crypto_verification_private S]}