If there’s one takeaway from the recent data security issues, it’s this — security is a paramount concern for any organization, large or small. That’s why it’s so confusing, then, to see so many organizations taking a lax approach towards security. It’s often seen as a secondary consideration, a last step, and because of this, it’s often given less time, less attention, and less respect.

While some of the reasons behind this are historical (and some would say somewhat valid), the times are changing – security is going to only be an ever-increasing concern for customers, and as such, implementing steps and systems to systematically address it now is a much better approach than simply trying to play catch-up later on.

Enter the concept of DevSecOps. DevSecOps is a trend in development that is extremely promising, bringing security, efficiency, and peace of mind. What exactly is it, and how does it work?

What is DevSecOps?

DevSecOps is not a framework, it’s not a guideline, and it’s not a product – this isn’t a “security integration” offering or anything of that sort. Put simply, DevSecOps is a fundamental rethinking and retooling of how security is handled throughout the entire software development lifecycle.

Traditionally, security was handled at the very end of the development stage. In some cases, this made sense — after all, to remain cutting edge in the days of multi-month development lifecycles, you would have to delay some last minute additions until the technology was appropriate and the vectors known. During this time, developers were thinking “we built this awesome thing – now how do we make it secure?”.

Unfortunately, this practice didn’t taper off as the months-long lifecycle did. Security still often remains an afterthought, which is troublesome. Because of this misguided thought process on security, there’s a division between those who value security and implement it wholeheartedly, and those who don’t see the point of doing it right away.

The Problem with Traditional Development

To be fair, this problem is inherent in the traditional development approach. At times, it’s hard to argue the value of security from a business point of view. After all, if the client is using the service, and it’s not being attacked, it’s “good enough” in the eyes of many business developers. Since this “good enough” mentality results in products out the door, developers have often been pressured to push out these products at their minimally viable state, whether they’re truly secure or not.

Of course, not all development teams are like this – a good many teams find themselves not pressured by these concerns, and instead find themselves pressured by chronological and economical constraints. When an app is released in a matter of weeks as opposed to a matter of months or years, the idea of having to spend almost as much time securing an API as you did developing the API at the end of the lifecycle is daunting, expensive, and, to some, of questionable value.

Assuming you could get passed all of these roadblocks, and assuming the business value justifies the time, there’s still the minor issue that security at the end of the lifecycle process is highly ineffective in the modern landscape. Threats evolve, and they do so rapidly. Securing your codebase with band-aids does nothing but solve the problem of today, while leaving the problems of tomorrow for other days.

And if that weren’t enough – are you getting tired of the issues piling up? There’s also the issue with work distribution that should be considered. The weight of securing a system falls squarely on one or more developers or security officers. With that comes all of the inefficiency of high-demand, low-supply, both in terms of time, morale, and result. This system is highly unbalanced, a situation which itself can lead to further issues.

Re-Thinking the Developer Relationship

To fix this, DevSecOps suggests that the entire issue should be reframed, and the fundamental developer relationship to the codebase restructured. In order to fix all of these issues, the relationship between the developer and the security approach should be turned on its head.

Using a DevSecOps approach, security is no longer something done at the end of a lengthy development process, but is done at the start and throughout the entire timeline. In other words, instead of starting with code and ending with security, you start with security and end with code! This entire process is leveled on the idea of securing first by considering the application design, the overall approach, the company ethos, the culture within the development team, and the architecture chosen to support the system.

Additionally, a big part of this approach is to look at automating certain security systems, gates, and tests during the construction and after the implementation. By combining this with iterative development and testing, systems can be proven before live tests and security can be guaranteed throughout the development process.

A big gain here is the fact that, by re-thinking the relationship on a fundamental level, the balance shift is so extremely valuable when it comes to analytical planning. Since security is integrated at the very start, you can better understand and quantify your risk/benefit balance, more effectively plan your security approach, and ultimately implement stronger, more effective risk tolerance and mitigation strategies.

Culture vs. Technology

It should be noted that not all of the changes that need to happen are technological or operational. Big changes must come to the business culture that supports the DevSecOp-integrated lifecycle. The problem here lies in the fact that the business culture places heavy consideration on value to the end customer – and while that is obviously the point of a business, it can cause significant issues in terms of a security-centric development cycle.

With a poor cultural approach, if the risk is considered low enough when compared to the relatively high cost of securing against it, a solution will be ignored. While this makes sense in some cases, the argument is fundamentally flawed, as the often-exorbitant cost in terms of work hours and economy is often that way due to the efficiency of traditional solutions rather than the solutions themselves.

In other words, adopting security from the get-go will result in lower costs to secure the API, and ultimately will shift the balance to cost ratio in a much more favorable spot when it comes to establishing security. Additionally, while the value of security has often been relegated to the realm of “technical gain”, the fact is that more users are concerned about their privacy and security – and adding security from the get-go is a major value addition.

Implementation

Now that we have some idea of what DevSecOps actually is, we need to look at how we might properly implement it. Keep in mind that while these are general guidelines, they do highlight major factors that make DevSecOps so powerful – accordingly, even if the answers herein aren’t a perfect fit for your given solution, you should try and use it nonetheless, changing it to your given situation and development approach.

Focus on Collaborative Building

At its core, DevSecOps is concerned primarily with collaboration. The very nature of the solution is that each team has to work together at every step to ensure security is properly integrated, tested, and iterated. Security from day one is a matter of having each business unit working together, but they must work together well – simply instructing them to support each other is not enough. Accordingly, ensuring that collaboration is not only possible, but well supported, is of paramount importance.

Enabling collaboration can take several forms. Having teams consult with one another at specific points in the project can help pinpoint early issues, and can help bring a fresh perspective to long-term, known ones as well. Utilizing collaborative construction and development environments can also go a long way towards enabling teams to work more effectively by allowing these units to view cooperating code and implementations in a holistic view. Finally, implementing a ticket system or other project management software can help align development at all levels,

Most importantly, and perhaps most often overlooked, implement a documentation system that not only supports collaborative editing, but also enables detailed, linked documentation throughout each step. You should document as if someone with no experience, no frame of reference, is going to depend on it at some point. The documentation should serve as a single source of truth, giving context to everything you do and setting the framework by which teams can work together. DevSecOps demands that you work not in isolation, but in collaborative environments, and the easiest way to kill this environment is to provide faulty, incomplete, or ineffective documentation.

Treat Security with Respect

Security should not be treated as a tertiary cost, but instead, as a vital, important part of the business value equation. Developers need to think of poor security as a potential negator of all the business value held by a solution. After all, how many API users would be willing to use a solution that publicly exposes data in plaintext without any sort of encryption or hashing?

Security should be seen as an enabler of value, and should be part of every single consideration at every single step of process and service development. At the start of each development stage, the question should not be just “how does this provide business value?”, but rather “how can we secure this while providing optimal business value in balance?”. Knowing how the API and its resources are exposed, how these exposures are being mitigated, and how the potential threats are handled is vitally important.

Standardize and Centralize

Part of ensuring the ability to secure each stage of your development cycle is to standardize the way the data is handled. By standardizing the transmission of data and processes from stage to stage and centralizing certain aspects of this process, you can bolt down and secure what needs to be unmovable, while facilitating collaborative work on those systems that must be changeable.

Each service should have the least privilege possible, and should only deal with standardized data. Wherever possible, this data should follow a known process of encryption and transference, and the movement of this data should likewise be standardized. User identity and access control can be centralized at this stage to ensure that it has its own secure handling, removing it as a potential point of failure at each individual stage.

Automate

One of the biggest opportunities underlying the DevSecOps approach is the movement towards automation. Implementing automated systems can help reduce the security workflow for your developers, and can help clarify and structure the collaborative environment that we’re looking to create. By automating security checks, implementing security scanners, automated testing, and code validation throughout the entire system, you can ensure compliance with your given approach and prevent issues from propagating throughout each stage.

Keep in mind that this automation is a long-term proposition. Periodic code reviews should be performed with up-to-date threat definitions and known vulnerabilities. Automated testing should occur during any and all updates to the codebase or maintenance functions. This automation can result in major time savings that facilitates more development time for features that increase business value, but this can only hold true if the systems are integrated early on and kept active over time.

Final Thoughts on DevSecOps

The important thing to remember with DecSecOps is that you’re not just adopting a framework or switching architectures – you’re fundamentally shifting the approach to development your entire organization is currently aligned with. Accordingly, keep in mind that this process will take some time, and will likely have some bumps in the road.

The good news, of course, is that once the shift is complete, implementing security at each level is really quite simple – it’s much more a mindset and general organizational feature than an effort expended. With this change of strategy and approach, you can reap benefits at every level of your organization.