Platform Engineering Challenge: Security vs. Dev Experience

As companies grow, their products mature and they build platforms, but their challenges grow as well.

One of those challenges is the precarious balancing act between security and usability, or developer experience (DX).

This article will list some examples of this struggle and how it can affect teams.

You will also learn about possible solutions and how to ease the process for product-focused software engineers without compromising on security or other crucial aspects of your platform.

What Are Some Typical Conflicts?

Often there is a conflict of priorities between the product developers and the platform developers. As a platform engineer, you want to build a secure foundation for future work. You need to develop a solution that is high quality, secure and extensible.

Product engineers, though, are often closer to customer-facing deadlines. They may feel the need to — or unfortunately be encouraged to — cut corners on things like testing and security to meet a deadline. This happens far more often than it should.

Developers can make decisions that have a negative impact on the application, platform or business security in response to time pressure. For example, perhaps your platform enforces Content Security Policy (CSP) rules. A developer team could inadvertently write some code that violates the CSP your team has configured. In cases like this, it is vital to reduce the friction as much as possible for the developers who are affected by the rules and security guardrails you enforce.

There are a few things that you can do to make things easier for developers. First, ensure that all developers affected by the new policies are aware of them. That lack of knowledge is a common reason for mistakes. Once the developer team knows the security policies, they can work with those policies in mind.

Next, remember that mistakes can happen. To mitigate this, automate as many items as possible with a proper continuous integration (CI) pipeline.

In the CSP example, it is possible to crawl your application automatically and report CSP violations with a little bit of initial setup. Automating the verification step can drastically reduce the possibility of mistakes. This doesn’t just apply to CSP; it is relevant for any check you want to implement to ensure that your devs follow particular guidelines or standards.

Another potential inter-team headache is vulnerabilities in third-party packages. Usually, the dev teams will install new packages. Depending on your business structure, though, it might fall to the platform engineering or security teams to fix any vulnerabilities found. Trying to manage this manually adds an item to your endless to-do list and can introduce more friction to the development process, which degrades the overall DX for everyone. As with CSP violations, you should be able to automate this.

There are many excellent services that focus on scanning codebase dependencies, detecting Common Vulnerabilities and Exposures (CVEs), and reporting them to you. Using them allows you to focus on fixing problems rather than burning time by manually cross-referencing the latest security advisories with your dependencies.

One such service is Snyk, which integrates with your CI and reports newfound vulnerabilities along with metadata such as severity level and suggested actions.

Developers tend to have so many duties — fixing bugs, patching vulnerabilities, adding new features — that they prefer the path of least resistance. That path, however, can be fraught with security issues.

Consider one of the quintessential web-security problems, SQL injection. Injection attacks usually happen because user input is added to the database without being properly sanitized, leading to potentially catastrophic consequences.

You can easily mitigate this issue while improving overall DX by using an object-relational mapping (ORM) library. These libraries abstract away the need to write raw SQL, but many also handle sanitizing values before sending them to the database.

You can eliminate a source of potential security issues by helping the dev team transition toward using these libraries. Standardizing on a single ORM rather than using direct SQL inserts improves DX by giving devs working on the codebase a standard reference for inserting and manipulating data, and by fostering a higher degree of consistency in the code.

Why Is This Important?

The balance between security and DX can be tricky, but getting it right is essential to the success of your teams and product. Consider a scenario where security is the most vital factor in your product. Your application is highly secure, but the pace of change has dropped drastically. Features take longer to release because devs have to battle against the guardrails. Changes are difficult and expensive to make, and your product may turn into a “dated legacy application.”

On the other hand, when speed and ease of development are the priority and security and stability an afterthought, the pace of change may be high, but so is the rate at which new issues are introduced. Bugs are forming left and right, and security vulnerabilities are popping up faster than you can fix them. The codebase might be a joy to work on and the team might appear productive, but the problems will be a nightmare to fix when the time comes.

Striking a balance between these two extremes is crucial to the long-term viability of a software product. Rather than viewing other departments or teams as adversaries, it is vital to recognize that everyone is on the same team and what is good for one team is likely good for the whole business.

The dev team should want to improve security and help the platform team improve things. The platform team should likewise want the dev experience on the product to be as seamless as possible so that the path of least resistance is the one that devs should be following anyway.

Too often, one team will consider something to be a “QA problem” or a “DevOps problem” and refuse to help solve it. This kind of responsibility avoidance can be mitigated by finding an equilibrium, where everyone benefits when everyone works together.

Conclusion

Developers tend to do their best work when they are working on systems they enjoy and find engaging. Improving the developer experience of a system is an effective way to enhance the quality of code and employee satisfaction in the long run, but you should not do that at the expense of security.

Similarly, when security is overprioritized, it leads to systems that are unpleasant for users and the developers who work on them. This can lead to subpar feature development and a pace of change that grinds to a halt. Striking a balance between these two priorities is tricky, but if you can pull it off, your team will be able to make magic happen.

If you use Kubernetes to deploy your applications and have felt the pain of configuring local clusters for each dev so that they can work with greater production parity, consider Loft, a service that makes Kubernetes highly accessible for developers by delivering a secure multitenant environment without compromising on DX.