1. What is the main purpose of DevSecOps?
The intention of DevSecOps is to build the mindset that everyone is responsible for security, and that security needs to be built into your process, rather than as a perimeter around apps and data. That said, security as a result of DevSecOps needs to impact the efficiency of the developer and DevOps process as little as possible. It therefore must focus on the right application at the right time and be carried out by the right individual/system.
Previously, during the Software Development Life Cycle (SDLC), traditional security teams were isolated to a specific team in the final stage of development. When development cycles used to last months or years, this wasn’t a problem. However, following a rise in agile, Continuous Integration (CI) and Continuous Deployment (CD) models, that kind of approach is no longer feasible.
2. What are the key considerations and components of DevSecOps?
DevSecOps involves creating a flexible collaboration between release engineers and security teams in order to build security into the DevOps process. The point of this is to avoid the bottleneck effect of older security models on the CI/CD pipeline, however, this process requires an increase in communication and shared responsibility between development, IT and security teams.
It’s probably also worth pointing out the primary benefits of a DevSecOps approach, I’d say there are two predominant ones: 1) it provides better ROI of existing security infrastructure; and 2) it leads to improved operational efficiencies across both security and IT.
By integrating security into the agile development process, organisations will be able to address security threats more effectively, and in real time. Making security a shared responsibility between development, IT and security teams should help change the perception that security is a burden, which slows down processes.
3. Why should application security be an integral part of a security team’s DevSecOps process?
Historically, application security has been seen as a distraction to app development and the application itself. The perception is that it increases timelines, decreases app performance and negatively affects the overall user experience. Unfortunately, many of these criticisms are accurate. Many processes such as encrypting data, user authentication and file validation before use, cause the application to slow down and in turn create a less ideal user experience.
To be able to effectively discuss the trade-offs of application performance and security, education of not only an organisation’s developers, but product managers and business-level team is key. Organisations need to show how seemingly benign implementation or coding techniques attract risk or introduce a vulnerability into an organisation’s application.
Security teams need to understand what is at risk if an application is compromised. This can be looked at by asking questions like, does the app require user credentials to access content? Is PII stored within the app? Are there vulnerable APIs? Does the app code inadvertently provide a roadmap for attackers into the back-end infrastructure?
It would also be important to consider how other organisations have fallen victim to attackers due to app vulnerabilities and what the impact was on the business once the eventual ‘hack’ hit the headlines and impacted reputation, revenue and customer base.
4. How should security teams align themselves with the developers considering that both teams use different tools?
There are a number of tools on the market today that can be integrated into the SDLC rather than bolted on towards the end. These tools can help a Dev team take a security-minded approach towards application development. Such tools include static code analysis tools that can be run each night on code submitted to the team’s local repository.
In addition to this, code protection solutions can be inserted into the SDLC, allowing developers to identify risks during development and insert a corresponding guard that can mitigate this risk. Leaving this process at the end of the SDLC isn’t a completely invalid approach, however, it can often leave the security team responsible for playing catch up before release, forcing them to identify every vulnerability at once, while also attempting to maintain a project’s release deadline.
5. Are there situations where DevSecOps simply won’t work?
No, but not every situation will benefit as much or in the ways expected, and in some cases the benefits can be reached by other means (where DevOps and agile development are not adopted).
I’d say that really a successful DevSecOps process should be reserved for those applications running in a zero-trust environment, for example, applications that are deployed into the outside world, via app stores or available on the public web.
I think legacy applications should typically be avoided when considering projects/applications to put through an organisation’s DevSecOps team. These applications should really be assessed using a formal Pen Test. Often the source code for these applications may not be readily available or may have been written by a third party. As such they should be assessed by an external team for serious violations and remediated when resources and time permit.
Applications that will be running within an organisation’s security perimeter or behind its physical walls without access to the outside world should be avoided. It’s possible that these applications will contain weaknesses or not fall in line with traditional secure coding practices, but the risk of these weaknesses being exploited is significantly less as they most likely would never be available to a potential attacker.
By avoiding the above, organisations can prioritise their DevSecOps efforts on protecting their most critical applications.
6. Do you have any tips on how organisations can streamline and optimise a DevSecOps process?
I think one key element to optimisation is focusing efforts with developers on good coding and where logical and possible, move other things outside the developer responsibilities. To maintain high business velocity, developer resources need to be spent on developing business functionality, so things like using security software development kits (SDKs) or implementing crypto can grind things to a halt. If these functions can be moved to the security team without creating new attack surfaces or vulnerabilities, that will allow more rapid time to market and optimisation of resources. Post-coding injection of SDK’s followed by protection, telemetry insertion, cryptographic implementations, and monitoring, will allow security teams to do what they know best, and developers can focus on good code that fulfils business objectives.
Rusty Carter, Vice President of Product Management, Arxan Technologies
Image Credit: Den Rise / Shutterstock