|This page is under construction|
The information provided below may not be complete or fully tested. Take care when following draft instructions.
|For more information on securing your data, see Information Protection @ MIT.|
On this page:
Building security into software during the early stages of the development cycle is the most effective way to limit the deployment of flawed software and address security issues before they become vulnerabilities. It is also less costly to incorporate security from the start than it is to try to add it on at the end. Secure development of software includes the identification of security requirements during the design phase, establishing a process of code reviews throughout the project, using code analysis tools, and testing code specifically for common security bugs.
Contact the Security Team while planning the features/functions of your application. Projects often start with identifying set of requirements to be implemented upon delivery. Including the security team at this stage will identify early on any security concerns and they can be incorporated into the design up front. To begin the process, provide Information Security, firstname.lastname@example.org, with a description of your project, timeline, and data involved.
Establish a code review process and follow secure coding practices from the start. This process should include peer reviews and be a part of your project plan/schedule. Additionally, software development tools such as Burp Suite , Fiddler, OWASP ZAP can further enhance security testing throughout a project life cycle. Once a prototype or beta version is available contact the security team to run an application security vulnerability scan and fuzz testing. This will identify common web application vulnerabilities such as sql injection, cross-site scripting, and cross site request forgery that are usually a result of underlying code.
Remediate any vulnerabilities from the code scans and set up a process to review/remediate any security issues that may arise once the application moves into production. Both should be a recurring process.
Another option post-production is to open up the code to security researchers not involved with the project. See MIT's Bug Bounty Program
- Open Web Application Security Project (OWASP) Top 10 Web Application Security Risks
- WhiteHat Security Learning Labs for DevSecOps
- Open Web Application Security Project (OWASP) Secure Software Development Lifecycle Project
- Veracode Secure Software Development Practices