Billions of lines of software code are generated by developers every year. And with the vast number of coding languages and the commonly adopted rush-to-production mindset, that makes software security an incredibly important and complex topic. Insecure software can leave systems and data vulnerable to cyber-attack and breach. Employing secure coding practices in every aspect of the coding process can not only help protect software applications, but also the digital experience of users interacting with them.
This guideline is intended to help developers, or anyone that is writing code, by providing best practices and security considerations. It is recommended for any software applications developed for or administered by the university.
Vanderbilt University requires adherence to this guideline for software applications that handle data subject to the Gramm-Leach Bliley Act (GLBA), which compels the adoption of secure software development practices.
- Align with NIST Cybersecurity Framework and Controls (NIST CSF). Specifically,
-
Function Category Subcategory Description Identify Asset Management ID.AM-2 Inventory software applications, preferably in the central IT asset inventory. Protect Data Security PR.DS-7 Physically or logically separate production environments from non-production (i.e., development, and test environments). Information Protection Processes and Procedures PR.IP-2 Adopt a development lifecycle. Include the phases noted on the Lifecycle Phases tab. PR.IP-3 Adopt a change management process, including version control.
-
- Incorporate secure coding practices in every phase of the software lifecycle and extend this to connected systems and interface components, such as databases, code repositories, and APIs.
- Regardless of the device or language used, use secure coding practices from guides such as OWASP Securing Coding Practices and CERT Secure Coding Standards.
- Train software developers periodically on secure coding practices and maintain a current knowledge of security threats.
- The OWASP Top 10 is an awareness document that lists the most critical software security risks. While it is primarily aimed at web applications, it is relevant for all software. Each risk is fully described, including example attack scenarios and recommendations for how to prevent.
- The CWE Top 25 is another community developed resource listing the most dangerous software weaknesses. It details software vulnerabilities that are easy to find and easy to exploit.
Recommended Lifecycle Phases (click each phase name to expand more detail):
Requirements
- Discover and plan to meet security-related needs such as,
- Identify the types of data that will be stored or processed by the app. If regulated data is involved, security measures beyond what is mentioned here may be necessary (e.g., GLBA FERPA, PCI).
- Understand the groups or users that will need to access the app and the type of access needed.
- Determine if connections to other systems will be needed.
Design
- Map out architecture and data flows.
- Create separate (isolated) production and non-production environments.
- Use up-to-date, supported OS versions on servers and system components.
- Define account roles and their permissions, ensuring that users do not have administrative privileges.
- Ensure connections or integrations align with the Network Security Standard.
Development
- Use current, secure options for supporting components such as libraries, packages, and tools (e.g., the latest version of a vendor-supplied library).
- Remove insecure services, protocols and/or ports including Anonymous FTP (Port 21), Telnet (Port 23), SNMPv1 (Port 161 and Port 162), SNMPv2 (Port 161 and Port 162).
- Remove preset default username and passwords provided by the vendor.
- Authenticate users prior to access, preferably using university authentication systems (e.g., SSO), except if the application is specifically intended for broad public use. Implement MFA where possible.
- Do not expose identifiers in the url/uri or hardcode credentials, access tokens, PII, PHI, etc.
- Use the least privilege possible to run components and execute commands.
- Assign permissions to roles or groups rather than individual accounts; Regularly review access and remove those that are no longer necessary.
- Validate input to protect against cross-site scripting, injection attacks, redirect attacks, and buffer overflow.
- Ensure that error handling does not reveal detailed system information, deny service, impair security mechanisms, or crash the system.
- Encrypt data that is categorized as Level 2 or higher, both in transit and at rest, according to the Encryption Standard. For example,
- Force https browser connections and disable http,
- Use strong one-way salted hashes for credential stores, and
- Use proper SSL certificates.
- Self-signed certificates are safe in a testing environment but should not be used in production.
- Use a Certificate Authority (CA) when moving from a testing environment to a production environment.
- Implement a session timeout where feasible and provide a logout function.
- Log application events.
- Support the removal of stored data when it is no longer needed.
Testing
- Do not use production data in a non-prod environment unless it meets the same security requirements of prod.
- Conduct iterative code review. Automated code testing/scanning is recommended. Some code repositories offer this feature.
Implementation
- Ensure separation of duties (e.g., the individual that writes the code does not also review and approve it for production).
- Remove test code or functionality not intended for production.
Operation and Maintenance
- Continue to check code iteratively.
- Patch regularly and adhere to the Vulnerability Management Policy and Standard.
- Remove obsolete or no longer supported/needed software applications from the network.
Top application security threats:
Secure coding practices:
- NIST SP 800-218 Secure Software Development Framework
- Carnegie Mellon University CERT Secure Coding Standards
- OWASP Secure Coding Practices Guide
- OWASP API Security Project
- OWASP Code Review Guide
Platform specific resources:
- AWS: Building Secure Code
- Azure Secure Development Best Practices
- GitHub Code Security
- GitLab Application Security
Software Developer Training:
Not sure how to start?
Get in touch if you don’t know where to begin, you can’t find the guidance needed on the website, or if you just want to learn more. The Office of Cybersecurity has subject matter expertise and is here for Vanderbilt community to discuss security questions or concerns.