This post is from the Arxan blog and has not been updated since the original publish date.
Part 2: App Security Should Be An Integral Part Of Your DevSecOps Process — Not an Afterthought
How to start implementing a DevSecOps process
As you may have read in our previous blog, you can have it all when it comes to secure code development and speed of delivery — if you are able to implement a DevSecOps process into your organization as a best practice. But where do you start and what are the key challenges you need to overcome?
1. Where does one start the entire DevSecOps process?
In order to successfully deploy a DevSecOps organization within your company, the first step is to create a well-defined process that can effectively assess applications making their way through your organization’s SDLC. Since every department is different there is no single process that could apply to everyone. As such, this process should account for all the subtle nuances within your organization.
The second and probably most important step in creating a DevSecOps team is education at the company level. If it is just the security team attempting to drive new requirements, then it will continually be an uphill climb. Developers and IT professionals need to have some sort of shared responsibility for the security of an organization, via the secure coding of each and every application delivered into market.
2. What are the challenges?
This question actually ties in with the second and probably most important step in developing a security-minded Development Operations team, and that is application security education at the company level. Many organizations fail if requirements are established in a silo and pushed down with no accountability for actual implementation — it has to be a team effort.
Historically, application security has been seen as a detraction 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 than ideal user experience.
In order to effectively discuss the tradeoffs of application performance and security, education of not only your developers, but product managers and business-level team is key. This education can be demonstrated with seminars that demonstrate real-world vulnerabilities and their deployment in the field. You need to show how seemingly benign implementation or coding techniques attracted risk or introduced a vulnerability into an organization’s application. You need to understand what is at risk if an application is compromised — does the app require user credentials to access content, is PII stored within the app, are API’s vulnerable, does app code inadvertently provide a roadmap for attackers into your back end infrastructure? How have other organizations fallen victim to attackers due to app vulnerabilities and what was the impact on the business once the eventual “hack” hit the the media headlines and impacted company’s reputation, revenue and customer base.
By moving these attacks from the abstract realm of “this might happen” and into reality, the arguments made by a successful DevSecOps team begin to have more weight. Less effort is required when enforcing new security features. Additionally, far less meetings would need to be attended when giving a justification for their implementation of a requirement and hopefully these demonstrations begins to foster an environment where a development team begins to proactively anticipate potential security-minded requirements.
3. Until now security teams have been considered gatekeepers. They come into picture at the end of a product development lifecycle. How should security teams align themselves with the developers considering that tools both the teams use are different?
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. They include static code analysis tools that can be run each night on code submitted to the team’s local repository.
Additionally, code protection solutions such as those offered by Arxan can be inserted into the SDLC that allow 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 is still a valid approach, but often leaves the team responsible for security playing catch up before release — forcing them to identify every vulnerability at once, while attempting to maintain a projects release deadline.
Unfortunately, not every project is well suited or should be put through a DevSecOps project. To learn more, read our next blog.