DevSecOps does not exist – Security is key to doing DevOps right

It’s taken less than a decade for DevOps – the collection of practices focusing on quick, short-loop, lifecycle of development, collaboration, and delivery of working products – to make it from the drawing board to a mainstream business strategy practiced by the majority of UK companies today.

Over the last couple of years, a new term has also crept into the business lexicon: DevSecOps. Insinuating the security function in this increasingly popular collaborative phenomenon is a notion that has both inspired and intimidated the people involved. Being an opaque and sometimes misunderstood function, security is often tacked onto the end of the developmental process and, as a result, blamed for delays in allowing new releases to reach the market.

However, this perception of security as an encumbrance which must be begrudgingly accommodated is as nonsensical as the recent practice of shoehorning it into the middle of DevOps terminology itself.

Indeed, when DevOps is executed properly, it must incorporate security as one of its intrinsic components, recognising security as the valuable asset that it is rather than the awkward afterthought some view it to be.

A Modern Approach to Software Testing

Assimilating security into the DevOps philosophy is a chance to introduce important protocols earlier into the developmental lifecycle, catching bugs, flaws and vulnerabilities before they have a chance to pose a serious problem and boosting the robustness of the code as a whole. Boiling it down to hard currency, doing security early (in dev) is cheaper than doing it later (in prod).

Beyond Penetration Testing

Pentest are a great way to add security assurance to a Business context. However, a misconception that we’ve seen over and over again, is that Security in DevOps is basically running a pentest after every release. This is wrong about 47 different ways (the quickest one is that a pentest normally takes days, and security testing in DevOps should take minutes) and also completely misses the chance to embed moder security practices into the development process.

A modern approach to software security can include the following techniques

• Static application security testing (SAST): A method of scanning the source code of an application before it has gone live to check for known issues, SAST can be implemented as soon as the code is deemed to be nearing completion. This avoids having to wait for a runtime-ready version and also allows developers to understand common mistakes they may be making (such as using weak code libraries, thus avoiding defects at the design stage), although it does have a tendency to produce too many false positives.
• Dynamic application security testing (DAST): Whereas SAST uses an inside-out approach to assess code security before the application goes live, DAST does the opposite. Set up to act as a malicious hacker approaching a runtime version of the software, DAST pinpoints exploitable vulnerabilities in the software’s composition, allowing developers to see how it will fare in the real world. As such, it represents an integral phase of any quality assurance lifecycle. Though it produces fewer undesirable findings than SAST, it can be trickier to interpret and as a result, slower to achieve actionable outcomes.
• Interactive application security testing (IAST): While both SAST and DAST have several years of field experience under their belts, IAST is a much newer and rawer method of security testing. Essentially, it combines what is best about both by introducing an agent into the instrumentation of the app itself, which can actively locate and expose only vulnerabilities which could potentially compromise the security of the system. This means that it generates almost zero false positives, though its novelty does mean it requires a greater degree of technical expertise than either of the other two methods and it’s also unable to handle large data stores at once.
• Runtime application security protection (RASP): RASP differs from the above methods in that it not only detects vulnerabilities in the system, it actually works to prevent malicious outsiders from exploiting them. A species of IAST, RASP is capable of continuously running security checks on the app in question, identifying potential threats and flagging them to the development team, as well as locking out any users which it suspects of having ill intentions. In this respect, it’s a tester and defender rolled into one.
• Unit Testing: is a testing framework that enables developers to test their code against a series of criteria. The great thing about using security stories in unit testing is that you are forced to think about your security criteria beforehand, as opposed to “discovering” security requirements through vulnerability identification. Unit testing is normally deployed as part of the automation of the SDLC, which means you don’t actually have to “do” testing – it just takes place as part of normal code promotion, and if a test fails, it automatically sends it back to the developer with the information they need to fix the issue.

These five methodologies are in various stages of their evolution, with the first two being fully-formed and widely-used methods of security testing and the latter still in different states of adoption. They also offer differing benefits and suffer from distinct drawbacks, so a combination of all – in line with your company’s own resources and needs – is the optimum approach to bringing security to bear on DevOps implementation.

Reaping the Fruits of Labour

Although most forward-thinking companies are now onboard with DevOps as an effective business strategy, too many are still reluctant to integrate security methods alongside it. This could be due to fears that it will cause undue delays to the process or that the development team doesn’t possess enough expertise in the realm of security practices, or even because the security professionals themselves don’t have confidence in replacing manual testing of a software’s defences with automation.

Such concerns are understandable and it’s undeniable that remodelling your security process to dovetail with DevOps necessitates some upheaval at the outset.

However, the benefits on offer far outweigh the efforts required. When working in tandem, development, operations and security departments can streamline processes, boost security, increase product quality and bring new quality releases into the market quicker than before, all in one fell swoop.

At Quorum Cyber, we can bring you these tangible benefits with none of the headaches. Our sophisticated DevOps Security model analyses the exact capabilities of your existing operations, then devises a regime of agile cyber-security practices tailored to complement the speed and capacity of your business. To learn more about how we can help you make security an asset rather than an afterthought, get in contact with us today.