...
| Cloak |
|---|
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. |
Non-Cryptographic Software Issues
The following are a few issues regarding your project's software as delivered that are not cryptographic-related.
Input Validation
...
Vulnerability Mitigation
Vulnerabilities Critical Fixed
Have you closed all issues filed against your project in sonarcloud that are CRITICAL or BLOCKERs?
| Cloak |
|---|
All critical vulnerabilities should be fixed rapidly after they are reported. |
Vulnerabilities Fixed 60 Days
Are all vulnerabilities that are reported against your project, either through an OJSI ticket or publicly from CVE reports, fixed within two months of being reported?
Hardening
Does your project apply hardening mechanisms so that software defects are less likely to result in security vulnerabilities?
...
| Cloak |
|---|
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?
|
...
Vulnerability Mitigation
Vulnerabilities Critical Fixed
Have you closed all issues filed against your project in sonarcloud that are CRITICAL or BLOCKERs?
...
| Cloak |
|---|
All critical vulnerabilities should be fixed rapidly after they are reported. |
...
Vulnerabilities Fixed 60 Days
Are all vulnerabilities that are reported against your project, either through an OJSI ticket or publicly from CVE reports, fixed within two months of being reported?
...
| Cloak |
|---|
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). |
...
| Cloak |
|---|
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. |
...
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). |
Non-Cryptographic Software Questions
The following are a few issues regarding your project's software as delivered that are not cryptographic-related.
Input Validation
Does your application accept input from potentially untrusted sources? If so, do you ensure that the input is valid before processing it?
| Cloak |
|---|
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. |
Hardening
Does your project apply hardening mechanisms so that software defects are less likely to result in security vulnerabilities?
| Cloak |
|---|
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?
|
Cryptographic-specific Software Questions
The following questions all deal with cryptographic issues.
...