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.

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

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.

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?

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.

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.

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.

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

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.