ONAP has long agreed that its projects should follow the principles of Secure Design, which is one of the CII Badging requirements. The primary reference given by CII for Secure Design is Saltzer & Schroeder.
The following documents are recommended reading on the topic of Secure Programming Practices. (A web search on "secure programming practices" will also produce many articles on the topic.)
- Open Web Application Security Project (OWASP) Secure Coding Practices Quick Reference Guide
- Software Assurance Forum for Excellence in Code (SAFECode) Fundamental Practices for Secure Software Development
- Oracle Secure Coding Guidelines for Java
- CMU Software Engineering Institute (SEI) CERT Coding Standards (C, C++, Android, Java, Perl)
As you read these, you'll find a number common themes. I particularly like how the SAFECode lays things out 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. OWASP concentrates on coding practices, with checklists in these categories:
| OWASP Coding Practice Checklists |
|---|
| Input Validation |
| Output Encoding |
| Authentication and Password Management |
| Session Management |
| Access Control |
| Cryptographic Practices |
| Error Handling and Logging |
| Data Protection |
| Communication Security |
| System Configuration |
| Database Security |
| File Management |
| Memory Management |
| General Coding Practices |
Invoking External Processes
The SECCOM was recently asked to make specific recommendations about how to safely invoke external programs from a language such as Python. In general, the problem boils down to:
- Use exact control over the PATH used to find your program, or prepend known locations to the beginning of the PATH. For example, you can add a line to the beginning of your program such as:
- shell: export PATH=/bin:/usr/bin
- or: export PATH="/bin:/usr/bin:$PATH"
- python: os.environ['PATH'] = '/bin:/usr/bin'
- or: os.environ['PATH'] = f"/bin:/usr/bin:{os.environ['PATH']}"
- Use exact control over the command line arguments. For example, in Python avoid using "shell=True" with the subprocess module's methods, which can allow unexpected parsing or expansion of the values being passed.
- Use exact control over the current directory before invoking a program using a relative path. For example, invoking "../somewhere/something" will act differently depending on where it is invoked.
- Use a "lint" finding program. For example,
- shell: use "shellcheck", which can be installed using "apt install -y shellcheck"
- python: there are a number lint-finding programs, such as "pylint" and "flakes8".