Open Source and Secure Coding Practices
0 likes157 views
The document discusses secure coding practices for open source software, emphasizing the importance of project maturity, community involvement, and governance for security. It outlines strategies for identifying high-risk areas, performing secure code reviews, and adopting both automated and manual review tools to enhance security. Additionally, it highlights the role of Common Vulnerabilities and Exposures (CVEs) and resources for learning about open source security.
Open Source and Secure Coding Practices
- 1. Open Source and Secure Coding Practices — Sahdev Zala Senior Software Engineer Open Source Developer
- 2. Is Open Source Software secure? 2 qDepends on the project § Maturity § Community § Maintainers § Governance qIssues can be caught and fixed early in the development cycle “We believe open source is a public good and across every industry we have a responsibility to come together to improve and support the security of open source software we all depend on. It is one of the most important things we can do.” Jim Zemlin Executive Director The Linux Foundation
- 3. Secure Coding Practices 3 q Identify high security risk areas to pay special attention § Refer to the project architecture q Perform secure code review § Automated § Manual § Define roles of the assessment team q Third party security audit q Address findings - short and longer term q Plan to publish CVEs
- 4. Security Checklist 4 q Authentication and Authorization § Cover every users, check password length, encryption, RBAC q TLS certificates § Make sure not to allow Monkey-In-The-Middle interference q Data validations § Validate all input parameters, URLs, expected data type, length, range q File permissions § Pay special attention to third party tools you are using for file management q Logging § Log error for any security alert q Error handling § Make sure that you are not leaking any sensitive information that can help hackers q Third party tools security compliance § Use the latest releases, keep eye on any CVE advisories q Documentation and Configuration
- 5. Secure Code Review 5 q Automated analysis § Static tools • Prevents coding mistakes that can impact security o e.g. variable shadowing, unreachable code • govet, staticcheck https://github.com/analysis-tools-dev/static- analysis#go § Dynamic tools • Fuzzing o Finds implementation bugs using malformed/semi-malformed data injection in an automated way e.g. https://github.com/google/gofuzz q Manual review § Tools are good at assessing large amounts of code and pointing out possible issues • BUT a person needs to verify every single result to determine if it is a real issue § There is no alternative to manual code review
- 6. File Permission 6 Do you see any security issue in this code snippet? // create directory with 0700 permission err := os.MkdirAll(dirPath, 0700) if err != nil { return err } qIf path is already an existing directory, MkdirAll does nothing and returns nil Ø Make sure that if directory already exist, it has the desired permission, if not raise an error
- 7. Data Validation 7 What is wrong here in this snippet? What’s the security issue? // update log with msg at given time interval func updateLog(timeVal string, msg string) (err error) { rv, err := strconv.Atoi(timeVal) if err != nil { t = time.Duration(int64(rv)) //update log } return err } q The return value of strconv.Atoi can be negative which is not handled in the code q Misconfiguration can be done by setting input to a negative value § Forever logging, filling all disk space and rendering application unable to process properly Ø Add validation to check for the negative value
- 8. CVEs through GitHub 8 q Common Vulnerabilities and Exposures (CVEs) § List of publicly disclosed computer security flaws q Do you know that GitHub has an integrated feature to request and publish CVEs? q Very handy if your project is hosted on the GitHub q Keep your CVEs details on your project GitHub repo
- 9. Conclusion 9 q Writing secure code is challenging but possible § Understand project architecture § Perform secure code review § Use tools like static analyzer and fuzzer § Manual review § Keep in mind that less popular features can be a source of problems q Third party audit is helpful q Creating and Publishing CVEs with GitHub is easy
- 10. Learning Resources 10 qOpen Source @ IBM § ibm.com/opensource qOWASP § owasp.org qOpenSSF § openssf.org qMITRE Corporation § mitre.org qTrail of Bits blogs § trailofbits.com
- 11. Thank You! Sahdev Zala Senior Software Engineer, IBM — spzala@us.ibm.com @sp_zala 11