teissTalk: Swerving the big threats to your application security

teissTalk host Geoff White was joined by  Andres Andreu, SVP, CISO, 2U; Dean Sapp, VP, Information Security, Risk and Compliance, Filevine; Michael Manrod, CISO, Grand Canyon Education, Inc.; and Adrian Winckles, Education Committee Chair, OWASP Foundation.

 

Views on news

 

Security Compass’ research found that while most developers believe their enterprise has a mature security posture, almost half find it challenging to stay up to date with current security and compliance-related activities. The “2022 Developer Perspectives on Application Security” study raises awareness about how automation can solve many challenges for developers in secure application development.

 

The study found that although, on average, 34% of software requirements are related in some way to security and compliance, only 25% of companies have incorporated security into the design stage of software development. Developers love to code quickly, and regard anything that slows down the process a hurdle, that’s why there is a natural tension between security, development and DevSecOps.

 

However, it’s not enough for developers to have security as an afterthought, it has to be baked into the code and dealt with along the full lifecycle of the software product. Seeing security controls as scope creep in software development can’t result in secure applications. Unfortunately, the agile methodology further incentivises developers to be fast and ignore security where possible.

 

On the other hand, there are also misfunctions on the security side that disempower developers, especially when they need to work with different interpretations of requirements. Dev teams do need the automation to be able to take security seriously (static code analysis, code scanning and tollgates), but security teams also have to be more thoughtful as to what to prioritise.

 

The likelihood of two vulnerabilities with the same score getting exploited may be radically different, and security should be able to factor that in.

 

Running simulations and putting back lessons learnt into the IR playbook

 

A continuous integration and continuous deployment (CI/CD) pipeline is a series of steps that must be performed in order to deliver a new version of software. It’s like an assembly line for code, where quality and security checks are integrated into the coding workflow.

 

The most important step to make security work in development would be to bridge the gap between developers and security teams, so they get an understanding of each other – developers, for example, should be knowledgeable about top CVEs. Companies seem to be oblivious to the fact that the later in the development cycle a vulnerability is spotted, the more it’ll cost to fix it.

 

Talking with developers about incidents that have recently happened can also be a good way of alerting them to how much bad security can cost the company.  Although  Ai-driven white box testing – an approach that allows testers to inspect and verify the code and infrastructure of a software system, and its integration with external systems – is automated, there is still plenty of room for manual and innovative humn processes. 

 

The best way to instil a security mindset into developers probably is to empower them with easy-to-use tools that can introduce a security functionality into software development. If it’s just one call to get a security functionality, they will be ready to make it, as long as security doesn’t impede the functionality of their application (API REST calls, for example, add latency to the application).

 

The panel’s advice

 

Articulate why a vulnerability needs to be fixed by developers, which may also involve building proof of concept exploits, and partner with them to help them use their time effectively.

 

As a security professional, you need to build a relationship with developers, pointing out how security adds value to the product.

 

For a list of code testing tools, click here.

 

Watch on-demand here.