...
As you read these, you'll find a number of common themes.
The SAFECode document lays things out very nicely into separate practices for Design, Coding, and Testing & Validation. Under Design, they discuss: Secure Design Principles, Threat modeling, Encryption Strategy, Standardize Identity and Access, and Establish Log and Audit Practices. Under Coding, they discuss: Coding Standards, Using safe functions only, Using code analysis tools, Handling data safely, and Error Handling. And under Testing, they discuss both Automated and Manual Testing.
The other documents are oriented specifically to coding. For example, OWASP has some nice good checklists in these categories:
| OWASP Coding Practice Checklists | ||
|---|---|---|
| Input Validation | Error Handling and Logging | Cryptographic Practices |
| Output Encoding | Data Protection | Memory Management |
| Authentication and Password Management | Communication Security | File Management |
| Session Management | System Configuration | General Coding Practices |
| Access Control | Database Security | |
| Cryptographic Practices | File Management | |
| General Coding Practices | ||
Invoking External Processes
...
- Use full paths for the programs you are executing. Note: While this can be done for shell scripts, this is most useful for non-shell scripts. For example,
- shell (but see the note above):
/bin/ls -l file
- python:
subprocess.Popen(["/bin/ls", "-l", "file"], ...)
...
os.environ['PATH'] = '/sbin:/usr/sbin:/bin:/usr/bin'
- Make certain that the current directory ("
.") and relative directories (those not starting with a "/") are not at the beginning or middle of the PATH.- Both an empty path element ("
::") and ":./:" are equivalent to including ".". That is, "::", ":.:", and ":./:" are all equivalent. - A leading "
:" is equivalent to a leading ".:".
- Both an empty path element ("
- If you must depend on an externally-provided path, combine prepending known locations to the beginning of the PATH, with sanitizing the rest of it. For example, you can add a line to the beginning of your program such as:
- shell:
...
- You will have to write the sanitize() function. Some things to consider are:
- The current directory is dangerous in the PATH, except possibly at the end. So one thing your sanitize function should do is to remove the current directory, or any aliases that map into the current directory (e.g.
::,:.:,:./:,:./.:, etc.). - Relative directories, those not starting with "/" are similarly dangerous.
- It's also dangerous for any of the directories found in the PATH to be world writable, where someone can create a program with the same name as a system tool invoked by your program. (Consider having a PATH with
/tmpin it, where someone could have placed a script named "ls".)
- The current directory is dangerous in the PATH, except possibly at the end. So one thing your sanitize function should do is to remove the current directory, or any aliases that map into the current directory (e.g.
- You will have to write the sanitize() function. Some things to consider are:
...
the use of code quality tool help the developper developer to fixe fix vulnerabilities early the vulnerability.
Inside the community, sonarcloud is the reference.
- https://sonarcloud.io/features (Detect, understand, and fix issues in your code, at the very earliest in your workflow)
- https://sonarcloud.io/organizations/onap/projects?sort=name (ONAP project)
Checking results and fix it fixing them regularly are one way to reduce risk
Software Composition Analysis
Like Code quality evalutionevaluation, the software compositio Analys help the communauty to reduce the software composition analysis helps the community reduce its risk.
https://snyk.io/blog/what-is-software-composition-analysis-sca-and-does-my-company-need-it/
What Is a software composition analysis (SCA)?
Software Composition Analysis (SCA) is an application security methodology for managing open source components. Using SCA, development teams can quickly track and analyze any open-source component brought into a project. SCA tools can discover all related components, their supporting libraries, and their direct and indirect dependencies. SCA tools can also detect software licenses, deprecated dependencies, as well as vulnerabilities and potential exploits. The scanning process generates a bill of materials (BOM), providing a complete inventory of a project’s software assets.
The community use uses whitesource and Nexus-IQ.
>>More information Code Scanning Tools and CI
Use
...
Safe and Secure Docker Images
To build ONAP images, the community provides secure docker images. These images , which are built from Alpine images.
- https://git.onap.org/integration/docker/onap-java11/about/
- https://git.onap.org/integration/docker/onap-python/about/
These images reduce the risk of threats, ; please use itthem.