Building Security into the Feature During the Design Phase

It is exciting how different disciplines can be merged to make the processes more efficient. In 2009, DevOps was coined to address the friction between the Development and Operations teams. As a result, the industry moved towards clubbing both teams together so that the development team was responsible for the entire cycle, from writing code to production deployment. Of course, who would better understand intricacies than the people who developed them? 

After this shift, we have seen features being shipped rapidly and the time to market for new features coming down rapidly. DevOps also served as the foundation for many other practices like MLOps, DataOps, GitOps, and undoubtedly many more have emerged.

Today we will talk about one such practice that many of you might be familiar with called the DevSecOps (Development Security Operations). So, what is DevSecOps?

Security has traditionally been treated as an afterthought, with teams shipping features to production first and then scrambling to deploy security remediations during a security review or an incident. With the surge in cybersecurity, supply chain, and other sophisticated attacks, the industry quickly realized that, like development and operations, security should also be part of the process. It should be embedded into the development lifecycle as early as possible because addressing security later can be expensive (both from an architecture and operations standpoint).

Now, let's discuss how it can be applied at various stages of our development lifecycle so that the code we are shipping is not only efficient but also secure. 

Usually, the process of shipping a feature involves:

1. Development – where the feature is built
2. Distribution – where the artifacts are created and prepared for delivery
3. Deployment – where the feature is released into the production environment

Let's discuss the steps we can take to enhance the security posture of the feature we're building during the development phase.

In the development phase, a feature goes through a design review, coding, and then a pull request review. As part of the design review, the feature owner discusses what the API contracts look like, what kind of databases we are using, indexing, caching strategies, user experience, and so on (not an exhaustive list).  In the security-first culture, it is also important to perform threat modeling. 

Best Practice 1: Perform Threat Modelling

Simply put, threat modeling is "the process of identifying vulnerabilities, performing a risk assessment and implementing the recommended mitigations so that the products/organizations security posture is not compromised."

Let's take an example to understand this. Imagine you are developing an API that:

• Lists products in your product catalog.
• Search for a product or product type.

GET /api/products?search=laptop

A threat model can look something like this:

These are something we can think of when looking at the product endpoints. The best part is that you don't need to be a security expert to recognize these vulnerabilities.

Tools like Microsoft Threat modeling tools and OWASP Threat Dragons can help identify them.

Example of a Threat Model in Microsoft Threat Modeling Tool

Analysis View

The analysis view of the threat modeling tool shows different attacks that can happen on the API.

Reviewing the threat model with your team can act as a brainstorming session to identify and mitigate as many security gaps as possible.

• Weak cryptographic usages. For example, usage of SHA1 or MD5 is considered weak. CA530 is an example of a warning that C# creates when any weak hash functions are used in the code.
• SQL injection attacks. CA2100 is an example that checks if the code is susceptible to any injection attacks
• Hardcoded passwords, weak authentication and authorization mechanisms, and infrastructure misconfigurations can also be detected with static analyzers.

There are existing tools in this space as well. SonarQube, CodeQL, Roslyn Analyzer, OWASP Dependency Check, and Snyk have some great offerings in this space.

Integrating static analysis into build pipelines is also important. It offers advantages like:

• Consistent vulnerability detection experience for your developers.
• Improves the security posture of your service because every production deployment must go through these steps.

Best Practice 3: Code Reviews From a Security Standpoint

While code reviews traditionally focus on identifying bugs and ensuring best practices, it is important to evaluate it from a security perspective as well. By considering the security implications of each pull request, you can proactively prevent future threats and safeguard the integrity of your application.

Conclusion

To conclude, with the growing sophistication in the cybersecurity landscape, it is important to consider security in the early phases instead of leaving it to the end. As part of that, incorporate threat modeling and automated static analysis into your regular development cycle.

In the upcoming articles, we will discuss what security practices we can incorporate during distribution, which involves scanning container images, dynamic application security testing (DAST), and artifact signing to protect the service from supply chain attacks.