To OWASP or not to OWASP? Security in the Age of Constant Threats

The OWASP Foundation (the Open Web Application Security Project) has been a pillar in software development for the past two decades, ensuring that engineers have the necessary insight to make applications safer against security threats. As part of their education effort, they propose and maintain a list of the top 10 application security risks. which they define as “a standard awareness document for developers and web application security, (…) a broad consensus about the most critical security risks to web applications”. While this is their most established initiative, they have a multitude of other projects, significantly contributing to the way application security is regarded nowadays.

At Maxcode we rely heavily on best practices and industry standards, yet we like to take a breather every now and then and think if certain approaches are still in line with the times. Technologies and trends evolve at the speed of light: for example, in the last years, we’ve seen a change in perspective from large monolith applications to microservice systems, from copy-pasting-installing a package on a machine to automatically building and deploying to a cloud service infrastructure, to name a few. Which raises the question of this foray into application security standards – in an era of continuous adjustments in tooling, technologies, and processes, are the OWASP initiatives still relevant as a foundation for application security?

Performing this analysis has been a stimulating experience, as it allowed us to think critically of industry standard tooling. While our instinct was to automatically assume their correctness and relevance, we went against it and formulated some advantages and disadvantages of following OWASP, their Top 10 lists and other projects.

What we love about OWASP:

➡️ 1. It keeps up to date with the latest trends. The OWASP community reviews and adjusts their main Top 10 list once every 2-3 years, the latest version being published in 2021. Alongside the well-known application security tally, there are also some more specific top 10 lists, referencing current technological tendencies, such as:

• OWASP Serverless Top 10;
• OWASP Mobile Top 10;
• OWASP Top 10 CI/CD Security Risks.

Sometimes designing a secure solution might be overwhelming without a plan on what to tackle first and what to follow. A list of key areas allows us to divide the problem into smaller pieces and manage each stage independently.

Maxcode encourages following OWASP Top 10 guidelines as a baseline for evaluating the security of the developed product, engaging developers to research and understand their code vulnerabilities, and adequately improving the quality of our applications. At the same time, we encourage teams to analyse and adapt recommendations for each specific use-case, creating tailor-made solutions and processes.

➡️ 2. It grows a community around security through open-source projects with the primary goal of educating developers, designers, and organizations. OWASP, together with its contributors, guards the Top 10s, created and expanded a comprehensive wiki, and organizes conferences, the latest one taking place in February 2023.

➡️ 3. It provides a framework that guides organizations to assess, formulate, and implement a strategy for software security that can be integrated into the SDLC by developing the OWASP SAMM framework (Software Assurance Maturity Model). SAMM is risk-driven and can be adjusted based on each organization, analyzing data from business specification to the operation and maintenance phase. The main advantages of using SAMM are:

• measurability;
• actionability – providing clear action items to improve the maturity level;
• agnosticism – technological and organizational.

Maxcode designed an internal standard, an adjusted SAMM model. Periodically our company evaluates the security maturity level by iterating through the following steps:

• assessing the organization’s current software security posture;
• defining the organization’s target;
• defining a roadmap to reach the targets;
• implementing the plan – define a set of steps on how to implement specific activities;
• roll-out – ensure that improvements are available and effectively used within the organization.

What we don’t really enjoy about OWASP:

➡️ 1. Its Top 10 lists are too generic or too long

OWASP Top 10 items are context dependent. For each OWASP guideline, engineers need to define a subset of security risks that are more specific to their solution, and thus easier to discover, fix, and test.

Ranking the vulnerabilities in the list is done by assessing their risk (Likelihood over Impact). Although the process is documented, the Likelihood and the Impact scores are a constantly debated subject within the security community.

When prioritizing work, our teams strike a balance between the client’s technical stack, business needs, of but also OWASP rankings. The development teams create a short checklist with the first 3-4 vulnerabilities that can be easily verified or addressed.

➡️ 2. Not one ring to rule them all – finding the right tools and adjusting the resources (time- capacity – money) might be hard to achieve when we have so many options.

For example, deciding on a cyber security tool that validates the application compliance against each rule and rule division is a tough call. The OWASP community developed OWASP ZAP, an open-source pen-testing tool with a not-so-user-friendly user experience. Competitor tools such as Acunetix, Invicti, or Burp Suite gained popularity by designing a more up-to-date user interface, good integrations with the latest CI/CD tools, and dynamic-beautified reports. On the other hand, all of this comes at a premium cost.

Let’s debate: to OWASP or not to OWASP?

Instead of providing a definitive answer, I think we are better off analysing if OWASP guidelines solve our issues from three perspectives:

• sufficiency: are they sufficient for ensuring security?
• absolute: are they the encompassing truth?
• baseline: are they a baseline?

Sufficiency – My view here is there needs to be more than OWASP. OWASP is not able to guard your application against all possible threats. Being too general and only sometimes providing a custom solution for our context does not give us the feeling of sufficiency.

Absolute – No, OWASP is not the be-all end-all solution. In our niche, we can find plenty of trustworthy communities where we put our faith in their knowledge and their ability to provide adequate solutions. In almost all cases, we end up with a good approach that we then refine and polish. OWASP does not have the absolute truth about high-risk vulnerabilities or which vulnerability should be tackled first.

Baseline – Yes, the OWASP Top 10s are providing a baseline for building the security strategy for our applications. They guide us through the main encountered threats and provide suggestions, but most importantly encourage us to go further and discover new threats.

Within the organization, it is essential to encourage a security culture instead of just using tools to provide metrics. In our case, getting developers and employees on board with becoming more security conscious enables our organization to handle vulnerabilities better and improve our applications.

Conclusion

The software landscape is chaotic, passing from baroque through cubism and reaching the surrealism of technological trends in a blink of an eye. Security vulnerabilities are keeping the same pace. We need to continuously learn, adjust, and improve our knowledge in tandem with hackers’ leverage of the attack mechanisms to exploit and steal sensitive data.

OWASP initiatives have become starting points, references, and guidance for web application development, representing the consensus of the most critical security risks to web applications. OWASP community continues to be a reliable partner in our development process, where we expand our knowledge of security practices and aim to find the best solutions for today’s security challenges.