teissTalk: Live at teissLondon2025- Enhancing AppSec with Application Security Posture Management

On 27 February 2025, teissTalk host Thom Langford was joined by John Heaton-Armstrong, Experienced Cyber security Leader, Confidential; Danny Dresner, Professor of Cyber security, The University of Manchester; Tiago Rosado, Chief Information Security Officer, Asite; and Derek Maki, VP Product Management, Veracode.

 

About appsec

To create threat models, first it must be mapped out what may go wrong when designing the software, as well as what the implications of certain  vulnerabilities will be in terms of data privacy, data sovereignty, client and contractual requirements. OWASP Top 10, which identifies the most critical security risks to web applications, is a simple tool that developers can compare their software against and make improvements accordingly.

 

Another important consideration is the standard of cryptography a new software has and whether it will be resistant to quantum computers that will probably cause a paradigm shift in cryptography in the next couple of years or so. It would make cyber defence much more straightforward if developer designed tools that talk to each other.

 

The more so because customers may in the future flee from walled gardens to overcome the problem of a vendor lock-in. Although APIs do a great job at integrating siloed systems, interoperability should be a major consideration for developers. Paradoxically, the industry must become more open to get more secure. 

 

Vulnerabilities are on the increase

The security industry has been trying to toss tickets over the wall to developers – an approach that hasn’t worked out. A study shows that application risk is decreasing in the first two years after release and then increases sharply as a result of an accumulating security debt. Security experts must get to the root of this at scale, identifying where these vulnerabilities originate and moving closer to automated remediation. Once a vulnerability is identified, it’s easier now to decide whether it’s exploitable or not with the help of ML. The main problem is that 21st century technology is being used in tandem with the tech of the 80s or even older. Most ATMs, for example, are still run on operating systems from the 2000s. Rather than nudging people to use old technology safely, we should remove the barriers that are preventing them from doing so. 

 

Where should we start addressing the challenge?

One approach is to start with the wetware and see technology only as a tool and invest in training developers to become aware of good security practices. Code security, for example, is often missing from university curricula. Building guardrails is also key, as well as identifying risk for developers in the IDE and provide them with easy fixes there. You also have to understand where you have controls across your CI/CD pipeline.

 

Meanwhile, it’s also key that threat management is dealt with before the design stage. While it may not sound realistic to get developers to read the threat management report, they might be empowered to get the necessary knowledge to do threat modelling by themselves. There is an international standard (ISO 25010) with a list of what developers must be told to build into the product to give it the longevity and interoperability that the brand is aiming for. At the end of the day, code security is the result of a decision a brand makes about how to spend resources – whether it wants to spend them on prevention or on cure and how this choice affects the RoI – whether better quality code or a more efficient use of resources is the business’s priority. ISO standards are as relevant as a business perceives them. They can be seen a drag and a business may go for other standards bodies such as the OIDF, which change things quickly and present a forward-facing view of application security.

 

Cyber Essentials get a lot of criticism for low requirements but, in fact, it was never supposed to be the be all and end all – only a starting point. One of the most important criteria for measuring the success of cyber security operations is the ability to cope with an incident. 

Fundamentals are called that for a reason. However, the 3 major fundamentals – vulnerability management, access management and role-based access – account for 99% of all the data breaches and the technology required to implement these controls are basic and not too costly. But they go against administrators’ ambition to have admin rights, as well as developers’ tendency to do what they like. There is also a visibility gap, and we can’t defend what we can’t see but basic cyber security tools can help with that. Also, businesses tend to care only about the price of the software but not the cost of maintenance.

 

How security-related tasks should be prioritised?

To establish priorities, one should be able to understand the impact of these systems. First of all, vulnerabilities that are never loaded into memory, aren’t in production or running should be de-prioritised and shouldn’t be sent to developers. Another example is a runtime vulnerability in a container that is not internet-facing. Tools like EPSS (Exploit Prediction Scoring System) by FIRST offer a simple way of calculating risk. For a proper, granular risk assessment exercise, use CVS.

 

If it’s about vulnerabilities in code, first find out if it’s fixable, and if it is, understand its level of criticality and the level and maturity of the exploit and how long it would take for perpetrators to exploit a particular vulnerability once they are inside the company’s infrastructure. To contain hacks, t’s important to abandon the habit of connecting everything with everything else. ASPM can help automate a lot of the contextual analysis problems by helping automate understanding runtime and how vulnerabilities interact in the business’s particular environment. Then ask yourself, if someone takes advantage of that vulnerability, will the business be able to cope?

 

Action items

• Run all the controls you have with your developers and review all your applications against all ISVS.
• Look hard at your perimeter and integration points.
• Think of your supply chain as part of your architecture. Adopt the IASMI cyber assurance standard (free).
• Look across the applications in your organisation and map out where you have controls in place that enable you to detect risk from pre-coding all the way to runtime.