There's lots of discussion about shifting-left in relation to software development. DevSecOps is a term coined by analysts and security practitioners to encourage development teams to consider security as they embark on their journey. Shifting-left, can mean different things to different people. It's not even a new concept. Many, if not all developers today will write unit tests so that code can be flagged as incorrectly designed or defective, the moment it has been written. Iterative development means that we see potentially many mini 'V-models' repeated across the time window of development. Ideally as testing models improve, tests will be made, before software has been written.
In this webinar we discuss potential options around how DevSecOps can live as part of a culture of wanting to shift-left, whilst at the same time being pragmatic about the bigger picture, high-velocity does not necessarily mean that every security test must take place at the speed of light. Some will agonise on whether a test should be allowed to break the build during CI, thus preventing automated delivery or deployment. If we can flag potentially vulnerable code, before the commit, we reduce the criticality of whether a build should proceed or fail - because the frequency of a security failure may be diminished by more hygienic coding practices. This is especially true of code that only survives in Production for short periods of time, again reducing the risk-window from a security escape.
Join this webinar to learn
The differences between using cloud vs on-premises software security
How to increase speed of security without increasing false positive rates