IT organisations are rapidly adopting DevOps and DevSecOps to build better applications, improve application security and support an influx of business demands. Shifting-left is not a new concept in IT, however the majority of shift-left methods remain focused on software testing. This is not enough to ensure software security from the outset.
Popular developer learning community DZone recommends shifting-left on design thinking. But they define design thinking as defining and understanding business requirements in the design stage of software development. No doubt, this is a very important step – one that should not be overlooked – particularly given the statistic that 70% of software projects fail due to poor requirements. What this mindset fails to recognise, though, is that software design should include an objective understanding and blueprint of as-is and to-be software architecture. You want to understand your current application and how security can be built-in as part of any changes or additions.
Establishing a blueprint of complex software of as-is software at the design stage guides ongoing software development and IT modernisation efforts by providing contextual software analysis at the beginning and along the way.
Research from Forrester suggests that incorporating Static Application Security Testing (SAST) in software design “remains the best prerelease testing tool for catching tricky data flow issues and issues such as cross-site request forgery (CSRF) that tools such as dynamic application security testing have trouble finding.” Security and development professionals should use SAST because:
- SAST helps developers fix security weaknesses while they develop.
- SAST helps teach developers how to write secure code.
Beyond the benefits listed by Forrester, introducing this kind of Software Intelligence at the design stage aids in the establishment of architectural rules that are specific to the requirements of your environment. In fact, I’m speaking on this exact subject at the upcoming Enterprise Security and Risk Management conference in London this month.
Building security into software must include:
- Ensuring application security in design and build stages via contextual software analysis or similar measures.
- Leveraging contextual software analysis to ensure security in design and build.
- Establishing a measurement process to benchmark and assess software risk in your development cycles.
If you’re beginning a new project or in the middle of a modernisation effort, check out our Two Key Steps to Improve Your Application Security Program. Getting accurate and comprehensive analytics about the quality and security of your software is possible and automatable.