Assessing Web Application Risk and Threats
A powerful first step in securing web applications is discovery. You can’t secure what you don’t know about! Start with an inventory of your software or application portfolio to understand sources of risk and what you want to prioritize.
For some this may be simple. For others it will be an essential inventory of what makes up your software and development process. Here are some questions to consider in your assessment of your portfolio:
- How many applications do you have?
- Where do they reside?
- Who owns them (and are they still around)?
Another part of discovery is finding out what your open-source dependencies are. The assessment of the software supply chain is so critical for modern software development, it’s been added later as its own item. We will get into more detail below.
Once your portfolio attack surface is understood, before you can check off this item, you need to start scanning for security flaws and vulnerabilities. Onboard applications with an initial Static Application Security Testing (SAST) or Software Composition Analysis (SCA) scan to establish a baseline and gain visibility. Many organizations prioritize certain applications and scan those first, and then continue with the others in waves. For further instructions on prioritization, please consult our free 6 Steps to Secure the SDLC eBook.
Establishing Policies and Framework
The next list item is crafting tailored security policies and guidelines for web application security. Just as the land must be assessed before a map can be made, your software or application portfolio must be assessed before policies and frameworks can be established.
Any specific compliance requirements, like NIST Compliance or ISO 20022 for the financial services industry, are a great place to start when looking to set policies. Public companies will greatly benefit from this step when it comes to compliance with new SEC rules for reporting material breaches.
The right testing platform will provide a dashboard of analytics for policy management and reporting. Then you can create clear goals for software security, report on progress, and guide development teams on what to fix. When teams are unified in objectives and tools are unified in a single platform, you simplify audits and gain centralized visibility into gaps across the organization.
Building a Security Culture, Mindset, and Team
No tool or even set of tools bring security; security must also be a mindset. A vital item on this checklist is building the security culture. While this is true across any organization, when it comes to securing web applications, it’s important for leaders to work on building a secure development mindset within teams developing software.
Here are a few great resources that can help with this:
- The Secure Coding Handbook
- Web Application Security: 5 Security Tips for Software Engineers
- The DevSecOps Playbook: Practical Steps for Producing Secure Software
An important consideration for CISOs when choosing a software security partner is that developers are the ones who must triage and address the findings. This is why it’s helpful when the tools work within developer workflows and utilize artificial intelligence (AI) to help with time-consuming tasks, such as flaw remediation.
Burn Down Tech Debt with AI Trained on Curated Data
Data from the State of Software Security 2023 tells us that by the time they move into production, nearly one-third of all applications have security flaws. Applications grow by about 40 percent year on year irrespective of their original size. As these apps grow and age, flaws accumulate, further driving up technical or security “debt.”
Nearly 70 percent of applications contain at least one security flaw by the time they have been in production for five years, and things do not get any better after that. By the time an application is 10 years old, there is a 90 percent chance that it has at least one flaw. Sights get grim when you combine this with data from a prior year’s report that tells us older applications with high flaw density experience much slower remediation times, adding an average of 63 days to close half of flaws.
This checklist wouldn’t be complete without tackling the critical risk and threats of technical debt. If you don’t have software engineers helping you burn down that tech debt because they’re too busy creating lucrative new innovations, what is a CISO to do?
Enter AI-generated secure code fixes developers can review and implement without writing any code. Veracode Fix helps you burn down the pile of tech debt you never thought you’d get to. Using proprietary data curated to generate high-quality secure code suggestions, teams can fix in minutes flaws that would otherwise persist for months or even years.
Take a Programmatic Approach that’s Continuous, Automated, and Measured
When it comes to securing web applications, “set it and forget it” is not the strategy. Your application security program must be continuous. The dilemma with software is that what was secure yesterday may not be secure today, so your program needs to be continuous, automated, and measured.
That’s why adopting DevSecOps makes so much sense. A successful DevOps practice is automated so security should be included in that automation. The DevSecOps Playbook walks you play-by-play from DevOps to DevSecOps with actionable guidance for getting started now.
Protect the Software Supply Chain and Vet Third-party Components
A critical item for companies securing web applications and developing in the cloud is to vet third-party libraries and dependencies and ensure they do not have critical open vulnerabilities. This item is not only important for security but also for maintaining legal and licensing requirements.
Here are a few tips for securing web applications from third-party risk:
- Establish SLA bound updates and patching cadence
- Track vulnerabilities and make them part of your tech risk register
- Determine and enforce role-based access for environments
Another software supply chain security tool every program needs is the ability to generate Software Bills of Material (SBOMs). SBOMs provide a detailed view of open-source components that can be used to understand the security of third-party libraries and dependencies used in an application. They are a critical aspect of compliance with the White House’s Executive Order on Cybersecurity.
Solidify Incident Response Plan
As discussed, the threat landscape never stays still. Monitor emerging threats and advisories and prepare an incident response plan that fits the nature of your risk landscape and organizational structure.
Communication with stakeholders, providing timely and accurate updates on the incident and its impact, is a critical part of the response plan. Documentation of the incident and response actions taken give you the information to improve your plan. Application security gets stronger with analysis, so make sure to include in your plan post-incident analysis and learning for future improvement.
Securing Web Applications Checklist Conclusion
As a tech leader, you stand at the helm of an organization’s defense against a relentless tide of web application threats. Take it from a CISO: securing web applications requires a strategic, holistic approach that goes beyond technology. Let the items in this blog serve as a guidepost propelling you towards a more secure digital future.
Please get in touch if you’d like help putting the items on this checklist into action.
