A report by the United States' Federal Bureau of Investigation (FBI) indicates that its Internet Crime Complaint Center (IC3) received over 467,000 complaints related to cybercrime in 2019. The cost of losses due to this class of crimes is estimated to be about U$3.5 billion (Source). An analysis of the numbers from the FBA shows that the losses had doubled since 2015 when they stood at $1.1 billion. This indicates that something needs to change if the security of company and customer assets is to be improved. The situation calls for a shift in thinking, right from early stages of the software development process.

For organizations dealing with code, it's time to ensure that software developers have the skill to design code that will be a step ahead of the criminals. This may be easy to say, but in practice, it will require a commitment to change our way of thinking. We will have to ditch the way of thinking where testing the security of code is something done right at the end - like some kind of an after-thought. The silos will have to fall, and security will need to be taken seriously by developers.

In this article, I want to suggest how organizations can change their way of thinking so that they can protect their assets and those of their clients. I will start by looking at the idea of DevOps and traditional security practices. My focus will be on how we can begin to think of security as code and get developers to consider security and security practitioners to think like developers. 

Security in The Age of DevOps

To understand the shift into an era where security and code are seen in a new way starts with comprehending the idea of DevOps. Between practitioners and academics, there is no coherent definition of what the concept of DevOps represents. However, there is a loose agreement that it denotes a concept where software development (represented by the Dev. part) and IT Operations (represented by the Ops) part are combined.

The aim is to reduce the time required to develop systems while ensuring that the delivery of software is continuous and of high quality. In practice, the idea can be divided into segments. These include product delivery, ongoing testing, quality testing, and development of features, and maintenance releases.  The aim is to ensure that the released software is not only reliable, but it is also secure. All this has to be done in less time than the traditional methods. The best DevOps teams are able to ship high quality software multiple times per day.

Adopting a DevOps attitude involves commissioning cultural changes in an organization. Organizations that embrace this framework will have to reconsider their operations, the roles of its developers, operators, and testers during the development and delivery of software. These groups will need to be trained to work in collaboration. This will involve dismantling the silos that are currently a feature in many organizations.  

In brief, I could say that the idea of DevOps sees security as code. This is the idea that I want to look at in this article. I aim to help an organization that seeks to shift into this way of thinking to identify some of the elements that it will need to address.

It’s Not Business As Usual

To create the paradigm shift into a DevOps way of thinking, your organization will need to start by understanding the prevailing practices and that something needs to change. In most companies today, the software development cycle begins with the development team getting a brief about what needs to be done. Off they go to do what they know best. Once they are done, the security team needs to review the new product to ensure that it does not have any security issues. This usually takes place a few weeks before the application is released.

As expected, the security team will identify several concerns that will need to be addressed during this process. With just a few weeks left before release, everybody goes into a panic mood because it becomes clear that there will be no way the deadlines will be met. At this stage, the company can either go ahead and release the application with the security glitches or postpone the release. Both choices will cost money and leave a few people unhappy. 

As you can see from the above scenario, the two teams in the organization (development and security) are concerned about different things. The development team wants to see their product going to the market within the deadlines. On the other hand, the security teams are aware that it will be impossible to release the software before the security issues are resolved. This is where the DevOps mentality comes in to assist.

Dismantling the Silos and Thinking of Security as Code

To solve the situation where the teams working on the development of software are reading from different pages, we need to start thinking about security as code. But how do we do that? We need to understand what the idea of security as code means.

Thinking of security as code is a framework where we start to make security part of the DevOps workflows and tools. This will involve changing systems so that we make changes to infrastructure and code so that security is incorporated into various stages of development. This means that the security team will not only see the code when it is finished but also during the entire development cycle. The collaboration between the teams will ensure that security problems will be identified and resolved early.

It is essential, however, to note that thinking of security as code should not add layers that will make the process more expensive and time-consuming. How do we ensure this? We ensure this by changing our security policies. The result of these changes should be the incorporation of tests into the pipeline and code itself.

When security tests are introduced at the time when the code is written, both time and money will be saved. If such a process is managed correctly, issues will be identified as they develop and corrected.  This is better than having them accumulate so that they all need to be resolved just before the application is released.

When security is seen as code and defined right at the beginning of the product development cycle, it becomes codified so that development teams can use it in the future. This creates a self-service solution for developers who want to make sure that they are creating secure code. This not only makes the process more efficient, but it also ensures that the process is less expensive. There are no unnecessary delays in releasing the product. 

Introducing Security into Code

Now that it's clear that there are benefits to thinking about security as code, where do we start? We need to ensure that all stakeholders understand the shift in thinking. This will be achieved by setting up practices that will be followed by all teams. Having appropriate policies in place will ensure that everyone knows the secure coding practices to follow. I will look at some of the practical measures your organization can implement.  

Keep It Simple

One of the reasons why people, in general, tend to ignore rules and guidelines is that they tend to be challenging to follow. In the same way, if you make your practices complex, likely, the people that are supposed to follow them will simply ignore them. 

Part of the process of simplifying things is to have as few tools and processes as possible. Examples of how you can do this include reusing those components you have come to trust and ensuring that approaches are centralized by making them fundamental parts of the design.

It's also essential to make sure that the security tools are integrated into environments that developers are already used to.  Examples include bug tracking systems, their IDE, source repository, and build environment.

Outline Security Requirements First

To ensure that everyone is clear about the security issues that could impact the final product, you will need to define these requirements early. This will include determining the threat modelling issues.

Outlining the security requirements will involve not only defining the security requirements but also codifying them right at the start of the project. Store these in a source code repository.

To ensure easy access to the requirements, security policies need to be automated. To evaluate an application's security policies, users click a button at any phase of the development. This is a fundamental step in thinking of security as code as it ensures ease of reuse of protection for different applications within an organization. This situation also ensures that there is no need for each application owner or department to define their separate policies; a time-consuming process. 

Ongoing Compliance

The paradigm shift into thinking of security as code will rely on seeing continuous compliance as a non-negotiable item. Start by ensuring that your policies and rules are clear to all stakeholders, making sure that everybody understands why they need to do something.

For example, compliance measures can include ensuring that codes are checked against specific standards such as well-known threats modelling. Other actions could involve having all codes being reviewed by peers before committing them to the primary repository. These are examples of the front line of defence that you could implement to streamline security into the coding process.

It will be easier for stakeholders to comply with the processes if they know them, and they are clear about why the processes need to be followed.

It will not be simple

Of course, from the way I put it in this article, it may look like a simple thing to create a mind shift where security starts to be seen as code. However, changing the way of doing things is not always going to be easy.

Developers writing code have a lot of pressure. There are several things they will need to focus on. For instance, they have to implement the feature, write code that is clean, testable, and maintainable, and other such tasks. Even though they may be keen to embrace secure coding practices, they may not have the time for it. All these are issues you will need to address as you patiently take your team on a new path.

Time to Shift Left

As can be seen from this article, if organizations are to secure their assets and those of their customers, they will need a paradigm shift. The old days of looking at security as an afterthought at the end of the development process are gone. We need to start seeing security as a fundamental element at the beginning of the application release. This is called shifting left. It denotes a situation where teams are being required to move faster and testing comes earlier in the process. 

An organization that shifts left is likely to be better at identifying problems. This will reduce the time required to deal with these issues before an application is deployed. Such a mind shift ensures that DevOps teams have the chance to authenticate security needs in shorter periods. Thinking of security as a code can facilitate this process. It assists in ensuring that the secure deployment is automated, a situation that does not only make the process easier but faster too.

While I support the idea of seeing security as code, there is a caveat. In essence, there are a lot of other issues that still need to be taken into account. While the idea will help in ensuring the security of code, no organization should make the mistake of thinking that this is the magic bullet that will solve all its security problems.

Security is a complex challenge that will not be fixed by one element. Hence, it is essential to realize that while thinking of security as code is a big step in securing released applications, it forms only one of the pillars. The real answer lies in creating a culture of sharing of information between the teams, defining clear deployment policies, and making it simple for stakeholders to be compliant. It involves automating processes so that users have access to the security protocols of any application and looking for ways of continuous improvement.