printer friendly version

Building a holistic application security process

Digital technology is the centrepiece of modern life today. All around us, technology is transforming business operations from end to end, from digital-first businesses to those simply updating existing processes. According to Gartner (www.securitysa.com/*gartner3), 65% of executives report that they accelerated the pace of their digital business initiatives in 2021. And this digital agility – technologies, work processes and activities – all depends on software to run. That makes it critical to be able to trust that the software is safe and secure, and that it can manage risks.

Boris Cipot.

Every modern business is a software business, so software is a big business risk. And as organisations look for ways to decrease their vulnerability to security breaches, many are putting the burden on the shoulders of software development teams to resolve all security issues. Or they are simply buying security software and trusting it to address risk. But in fact, a holistic approach to application security (AppSec) is the better approach to securing the organisation and its software.

What does it mean to build a holistic AppSec process? Industry sectors and markets are all different, each with unique requirements. But they share the need to develop safe and secure software, obey security standards and react to threats to keep their business and customers safe.

A holistic approach involves understanding internal and external threats and risks, building a strong foundation for your AppSec process and maximising your AppSec tools (www.securitysa.com/*arrow). Application security isn’t simply about deploying tools and running tests. It’s about aligning people, process and technology to address application security risks holistically (www.securitysa.com/*arrow1).

Application security

More complexity, shorter development cycles, and the interconnectedness and always-on nature of software, give hackers a continuously available tech surface to try to exploit. Securing that software takes more than just tools – it requires prioritising security and managing it proactively. That means aligning people, processes and technology to address security risks based on an organisation’s unique policies and business objectives.

We often focus on the technology and tools, and forget the processes, when in fact the tools exist to complement the processes. If you focus on only one point of the software development lifecycle (SDLC), your security profile is incomplete. It’s necessary to consider the whole lifecycle. Place security at each and every step of the development process, including coding, building, testing, release, deployment, monitoring, etc.

Organisations using software live in a constant threat state. For open-source software it can be days, months or years between the time a vulnerability is introduced and when it is discovered. But once that breach is known, it’s vulnerable, because hackers are always searching and ready to strike. For proprietary software, you usually only learn about a vulnerability when that vulnerability is exploited.

Building an AppSec culture

Traditional methods of security slow down DevOps (www.securitysa.com/*arrow3) velocity, and large AppSec testing tools can congest the build, test and release pipelines. More security tools mean more testing, which means more findings that must be correlated, deduplicated and prioritised to ensure that developers aren’t overwhelmed with data and unable to focus on the security issues that matter most.

A true AppSec culture is one in which people, processes and technologies are aligned to minimise risk and transform the business. It is a culture shared by the whole organisation, not just in the IT or development teams. A comprehensive AppSec culture includes security champions, metrics, planning, a DevSecOps (www.securitysa.com/*arrow2) maturity framework, integrated DevSecOps and training.

Security champions. Security champions are security-minded employees on the IT or development team, or those who have expertise in security and want to take ownership of the application security process by helping enforce that process throughout the SDLC. Champions also educate development teams on security best-practices and stay informed of current vulnerabilities and threats for software your organisation uses, and internally track vulnerabilities and issues across teams.

Metrics. If you don’t know where you’re at right now, you won’t know what you need to develop or invest in for the future. A key step is developing a measuring stick to understand how existing processes are working and where they can benefit from improvement, or additional resources or budget.

Planning. It’s important to build an actionable security plan based on your organisation’s policies. A security plan is a living document, and it will evolve and mature as you use it, as you discover more about the people, processes and technologies involved, and as you discover deficits. Any plan is good as long as it works, and then you can create a new one.

To create (or update) a security plan, an organisation must build consensus for objectives, determine the current state of secure SDLC, identify a target state, and define the budget and the path forward.

DevSecOps maturity. Key to a robust, holistic AppSec process is establishing a DevSecOps maturity framework. That means defining governance and processes, creating a secure design and architecture, and having all processes function within this framework. Then you can identify what tools are deployed in every step of DevSecOps and compare it to the plan.

Integrated DevSecOps. Integrate AppSec naturally in the organisation and at every phase of software development.

Training. Training employees so they know how to handle DevSecOps tools is vital. Using a tool incorrectly is as bad as not having a tool at all.

Intelligent, policy-driven DevSecOps

It is not possible for a security programme to be successful without the right tools. Test at the right time and the right level so you can build truly secure software. Tools can show deficits in security and inform you about how to handle them efficiently. But tools alone are not enough. An integrated solution centralises the view and integrates feedback from an organisation’s security tools, enabling the development team to prioritise tickets, track remediation and provide actionable insights.

Share this article:

Further reading: