The unfortunate reality is this: application security is in an abysmal state. Industry research reveals that 80% of tested web apps contain at least one bug. This rampant software insecurity proves devastating to the 60% of small businesses that close within six months of being hit by a cyber-attack. The balance of power is overwhelmingly tipped in the favor of threat actors when most apps are vulnerable and many businesses cannot acquire security experts.
Various government agencies have noticed the continual growth and increasing sophistication of cyberattacks and are taking strong steps to improve security policies. Some of these approaches involve punishing organizations for their response to security failures or fining them for losing data. It may be only a matter of time before application developers are held accountable for the quality and security of their code.
The value of catching vulnerabilities early in the application development process cannot be overstated. Reports from the National Institute of Standard Technology (NIST) and private industry agree that the costs for fixing flawed code rise exponentially over time.
Developers, the architects of code, lay the foundation upon which other pieces of enterprise communications, data processes, and network infrastructure are built. They bear the responsibility of creating the most secure foundation possible for their customers — a task made easier by implementing security in the SDLC.
Application stakeholders will agree upon the capabilities, general performance, and other attributes the finished app must ultimately possess during this phase. When the application is released, it will be largely assessed upon how well it met the stated requirements. Unfortunately, many teams may view implementing security practices as a roadblock to quickly achieving the benchmarks required for the app to progress. This can be resolved by defining robust security as one of the app’s primary requirements from the start. The specifics of how the application will meet its requirements may vary, but security must still play a role in this process.
Requirement phase security steps:
- Since the application is largely an abstract concept during this phase, implementing some generic threat modeling may be helpful. For example, if a mobile game app is being developed, research which attack vectors are most often exploited to compromise these types of applications. Freely available resources like the Open Web Application Security Project (OWASP) can greatly assist with general threat modeling.
- Secure coding principles should be discussed, agreed upon, and provided to developers. These principles should be adhered to throughout the project.
- Security responsibilities for the project should be clearly defined and assigned to responsible parties.
The design phase focuses on determining the specifics of how an app will meet its requirements. The development team creates a roadmap of specific techniques, tools, and approaches that will be used to create that app. Taking steps to increase app security during this phase will pay large dividends later, in the form of work-hours saved and headaches avoided.
Design phase security steps:
- Consider how an adversary might subvert or corrupt each task or activity and application performs. For example, if a program must collect data from a user, how might the proposed process be abused or exploited by bad actors? If data must be stored, how might motivated attackers attempt to gain unauthorized access? Asking and answering these questions now can provide valuable guidance for securely coding the app in the next phase.
- Determine how data, application, and user integrity will be maintained once the app is released. What technologies will be key for ensuring the app runs securely: cryptography, 2FA, biometrics, etc.? How will these technologies be integrated and maintained throughout the project?
Dedicated software developers take the abstract concept of the app and turn it into a digital reality during the coding phase. Adding extra steps to integrate security into this phase may provoke pushback from developers who are under the pressure of meeting deadlines. However, the time lost securing the coding phase is an investment. It pays off by creating fewer problems to fix in later phases when corrective actions are more expensive and time-consuming.
Coding phase security steps:
- Use the most secure programming language and framework possible for developing the app.
- Follow processes that enforce good security hygiene: validate and sanitize data, secure outgoing communications, adhere to the principle of least-privileged, etc.
- Perform static analysis software testing (SAST) to discover bugs and vulnerabilities in the app code. Using next-generation testing (NG SAST) can vastly improve upon legacy methods by evaluating multiple properties of code at once.
- Reference helpful material like the OWASP Top Ten web application security risks, API security risks, and mobile security risks lists to ensure the app is avoiding common security pitfalls.
Development teams that delayed security processes until this phase may lose countless work-hours fixing bad code as a result. For teams that implemented security throughout the SDLC, the testing phase will be more of a quick tune-up than an exhausting overhaul. In either case, the testing phase subjects the app to various human and automated analysis processes focused on discovering vulnerable and flawed code.
Testing phase security steps:
- For testing open-source dependencies, SCA offers insights into known, vulnerable, software components. Intelligent SCA, or I-SCA, provides additional insights that can result in a 92% support ticket reduction by determining attacker reachability.
- Perform run-time analysis, using dynamic application security testing (DAST) and interactive application security testing (IAST) tools.
- Create robust continuous integration/continuous delivery (CI/CD) practices for identifying and fixing bugs.
The release phase covers the deployment, implementation, and maintenance of the app. As such, it offers several opportunities to ensure the application is resilient to current and future security threats. This phase marks the point where security concerns shift from writing a bullet-proof application to focusing on how developers should address emerging threats. New technology and innovative techniques may reveal vulnerabilities that were not known during the creation of the app. Having a robust system for detecting and addressing these new threats is critical for maintaining app security.
Release phase security steps:
- If deploying directly to a customer, it is important to assess server and network configurations for security vulnerabilities.
- Ensure the application is protected by a web application firewall (WAF). A WAF protects applications from malicious bot activity, adds security features (e.g., CAPTCHA), and enforces protection rules that address other security threats.
- Continuously collect and analyze security data related to the app. When issues are discovered, remediate them and perform updates immediately.
- Once the application is released, measures like bug bounties and penetration tests can be implemented to find security issues before attackers do.
Application security is the foundation upon which all other pillars of cybersecurity are built. Individual developers continuously working to write secure code has an immeasurable, positive, long-term impact on the overall health of the cybersecurity ecosystem. If you would like more information on next-generation technologies that can help you release secure code, visit ShiftLeft. If you are interested in seeing how a next-generation application security testing platform can help you meet the demands of a modern SDLC, sign up for a free account at https://www.shiftleft.io/register.