You are viewing content from a past/completed QCon

Presentation: Security Vulnerabilities Decomposition

Track: Scaling Security, from Device to Cloud

Location: St James, 4th flr.

Duration: 2:55pm - 3:45pm

Day of week: Wednesday

Slides: Download Slides

Share this on:

This presentation is now available to view on

Watch video with transcript

What You’ll Learn

  1. Find out how to prevent security vulnerabilities from onset.
  2. Learn to decompose security vulnerabilities into the security controls preventing them.


In most companies security is driven by compliance regulations. The policies are designed to contain the CWEs each company is interested to comply with. The result of this approach is a high number of insecure applications are still produced and injection is still King. Is there another way to secure the software in a more developer friendly manner? 

This presentation will look at security vulnerabilities from a different angle.  We will decompose the vulnerabilities into the security controls that prevent them and developers are familiar with. We will flip the security from focusing on vulnerabilities (measured at the end) to focus on the security controls which can be used by developers from beginning in software development cycle. 

Recommended to all developers looking to integrate security in their software applications.


What is the work you're doing today?


Today I work as an application security consultant at Veracode. As part of my job, I help developers and software architects to secure their software. I work with development teams and help them fix correctly the security flaws identified by automated tools, to ensure that they have been remediated in a secure manner.


What are the goals for your talk?


This talk is based on my experience from the work I do. What I see a lot of, is when companies are implementing application security, they are primarily checking the software for most common vulnerabilities, like the OWASP Top 10, for example. The problem with this approach is that you can check for these vulnerabilities only at the end, after the software has been developed. After all, you cannot test for SQL injection before you have written the software which connects to the database. My primary goal for this talk is to empower developers to look at application security from another point of view. If we go back to some basics, security vulnerabilities are just software flaws which have been introduced at various stages of the software development: either at architecture, at design or at the code level. The concept I will explore as part of this talk is to analyze these software vulnerabilities, to decompose them to identify the security controls which prevent them,  are familiar to developers, and can be used on a regular basis when writing the software. The final goal is to give the audience, the developers, another view where we flip the security, and instead of focusing on the vulnerabilities (which can be measured only at the end) to focus instead on the security controls which prevent these vulnerabilities and can be used in the software from the beginning.


What key takeaways do you want people to leave the talk with?


What I like the attendees to take away is that in order to build more secure software, we should focus on one category of vulnerabilities at a time. And for each category of vulnerabilities, we should first identify the security controls which prevent the vulnerability. Then, identify the best place to apply those security controls in the software to effectively prevent that vulnerability. For example, in the latest OWASP Top 10, there have been few new entries. One of them is A4-XML External Entities where by default, older XML processors allow specification of an external entity. If developers want to prevent their software having this vulnerability, the first thing is to identify the security control. For XXE,  the control is hardening the software by disabling parsing XML external entities. Next, is to identify the best place to apply this control when writing the software. It depends on the framework/language. For example, in Java, the best place is before parsing the XML document. There we need to harden the configuration by writing few extra lines of code. And by doing this every time an XML document is parsed, we ensure that the software will proactively prevent this particular vulnerability. This angle of securing the software, by identifying the security controls which must be used, is what I would like the attendees of this conference ( senior developers, tech leads, and the software architects) to take back to their teams and start applying in their software development cycle.

Speaker: Katy Anton

Principal Application Security Consultant @Veracode

Katy Anton is a security professional with a background in software development. An international public speaker, she enjoys speaking about software security and how to secure software applications.

In her previous roles she led software development teams and implemented security best practices in software development life cycle. As part of her work she got involved in OWASP Top Ten Proactive Controls project where she joined as project leader.

In her current role as Application Security Consultant, Katy works with security teams and software developers around the world and helps them secure their software.

Find Katy Anton at

Last Year's Tracks