DevSecOps is nothing without DevEx

Introduction

"Shift-Left" is great. Having a proactive mindset that puts an emphasis on integrating security early in the software development process makes it easier to prevent problems rather than deal with them after they occur. 

The thing is, this DevSecOps (Development, Security, and Operations) mindset often creates a reality in which developers find themselves buried under a mountain of extra tasks and tools. This is primarily due to the fact that DevSecOps tools, especially in the context of application security, tend to measure rather than actively influence the security posture of the application you’re building. This mostly results in an endless backlog of security findings, instead of providing you with the tools required to make your app more secure.

Proactive DevSecOps

We talked about the importance of turning proactive measurement into proactive design in a previous article. This time we want to focus on a crucial aspect of making that happen: Putting an emphasis on Developer Experience (DevEx).

As a dev tool company in the application security field, we've learned a lot about what developers come to expect when dealing with the implementation of new tools into their workflow. In this blog, we want to outline these expectations in the form of best practices you might want to consider when building security features (or adopting existing security tools) that help your developers create a more secure application and DevSecOps pipeline instead of frustrating them. 

With the help of a practical example from the world of application-level access control, we'll explore how improved DevEx can lead to safer applications and happier developers. 

First things first - let’s understand what DevEx actually is.

What is Developer Experience (DevEx)

Much like how User Experience (UX) focuses on the end user's interaction with software products, Developer Experience (DevEx) focuses on the tools, practices, and processes used by developers during the development process. 

The platforms, tools, and environments used by developers need to be intuitive, efficient, and streamlined, making the development process smoother and more productive. In the context of integrating security measures like "Shift-Left", good DevEx means that security tools and protocols seamlessly blend into a developer's workflow, rather than disrupt or complicate it. When security becomes a natural part of the development process, it's more likely to be implemented consistently and effectively.

Giving our developers a good DevEx is key to encouraging this type of proactive approach toward application security. It does so by replacing the endless backlog generated by measurement-based tools with the ability to actively influence their application’s security posture as part of their development workflow. 

To better understand how let’s look into a concrete example: application-level access control. 

The case study: Application-level access control

Access control is comprised of two significant steps in your application’s workflow - 

Authentication, which is about identifying who is trying to access your application, and Authorization, which is about enforcing what they’re allowed to do once they’re in. 

As similar as the two may sound, there is not only a crucial difference between the functionality of these two elements but also a major difference in the way these are handled in the development process. 

Many companies offer authentication services, allowing developers to easily verify user identities. Determining what actions a user can take after they log in, or, authorization, poses a bigger challenge.

Most authentication tools provide developers with straightforward code to integrate into their applications. They often supply an SDK, which gives developers a user object, based on which they can make the decision of allowed/denied. In authorization, the same kind of "if" statement we can use to make an allow/deny decision is much harder to make. 

if (!user) {
   return;}

if (!allowed(
      user,
      action,
      resource
   )) {
   return;
}

Few tools support this nuanced level of user permission checking, especially when it comes to dealing with authorization models more complex than basic Access Control Lists (ASL), such as RBAC, ABAC, and ReBAC. This usually results in developers home-brewing their own authorization solutions - leading to problematic results, with only measurement-based tools available to amend them.

In the traditional "Shift-Left" approach of handling application-level authorization, a tool would usually be applied to check the code of the access control layer for mistakes. This often creates extra work for the developer, instead of aiding them with the implementation process.

The Issue with Homebrew Security

Let’s look at a typical way of implementing application-level authorization: 

// Middleware
if (req.user.roles.indexOf(role) === -1) {
    return res.send(403);
}

// Endpoint
@authz('admin')
const Document = () => {
    ...
}

It typically begins with decorators. By employing a decorator, a developer can set security requirements, such as ensuring that only admin users can execute certain operations on specific resources. To achieve this, the developer constructs a middleware—a function that operates right before the endpoint is called—to verify if a user possesses the "admin" role.

Application security and usability requirements are, however, usually more nuanced than this. This usually leads to developers writing more complex code in the middleware, allowing decorators to assign multiple permission models to endpoints.

As the authorization code evolves, it becomes difficult to ensure in a "Shift-Left" approach that authorization is adequately secure due to its decentralized nature, and we're often left in the dark about how to thoroughly analyze and review the decisions made during the authorization process.

Without a dedicated authorization system in place, a security engineer would examine the code, see the middleware, and recognize the framework that was promised to be secure, but the code offers no clarity on the breach's origin.

So how can we avoid that? By either creating or adopting authorization tools that follow DevEx best practices.

Best Practices for Security DevEx

In designing an optimal authorization system, a focus on developer experience (DevEx) is crucial. The system should be built in a way that developers find convenient and efficient to use, rather than an obstacle to their workflow. Here are some best practices we decided to follow while creating Permit.io we think can help you achieve that:

• Platform Independence: The authorization system should be cross-platform, ensuring developers don't have to build extensive, unique layers for each application just to enforce permissions.

• Performance: Developers enforce permissions across various stages of their processes. Therefore, the authorization system needs to be high-performing, ensuring it doesn't hinder or delay API calls or other operations.

• Zero-Effort Deployment: Developers are more likely to embrace an authorization system that is easy to deploy. If setting up the system feels like a hefty project, it will most likely never be prioritized. The deployment process needs to be as streamlined and hassle-free as possible.

• Decentralized Architecture: With the rise of microservices and diverse deployment environments, an ideal authorization system should support decentralized applications. While the policy system might be unified or centralized, it should cater to applications scattered across different environments.

• Seamless Data & Configuration Syncing: For effective policy analysis, the authorization system should integrate seamlessly with various data sources. Developers should be confident that the system is always up-to-date with the latest permission configurations, ensuring data and settings synchronization without hitches.

For an authorization system to be widely adopted by developers, it should seamlessly fit into their workflow. The system should be efficient, flexible, and not add additional burdens to the development process. When these conditions are met, developers are more likely to prioritize and integrate the authorization system in a proper manner, enhancing overall application security.

Bottom line: DevEx is Key!

Looking at the OWASP top 10 Security risks in the past years, we can see the highest-ranked access control vulnerabilities changed from authentication to authorization. Today, authorization alone holds three of the top 10 places on the OWASP top 10 API Security risks for 2023 list. 

Authentication has changed, taking a significant leap toward providing developers with tools that help them impact their application’s security posture instead of just measuring it by providing them with a good developer experience. It’s time authorization goes through the same process. 

We hope these best practices help you choose better tools that make good use of the “Shift-Left” trend, focusing on impacting development from day one. 

Want to learn more about Authorization and access control? Join our Slack Community, where world-class authorization specialists and hundreds of devs are discussing, building, and implementing authorization together.