Virtualization Technology News and Information
Article
RSS
The Platform Engineering Challenge: Security vs Developer Experience

By Cameron Pavey Full-stack Developer

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 in order 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 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 be installing new packages. Depending on your business structure, though, it might fall to the platform 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 over-prioritized 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 multi-tenant environment without compromising on DX.

##

To hear more about cloud native topics, join the Cloud Native Computing Foundation and cloud native community at KubeCon+CloudNativeCon North America 2021 - October 11-15, 2021       

ABOUT THE AUTHOR

Cameron Pavey Full-stack Developer

Cameron Pavey 

Cameron is a full-stack dev living and working in Melbourne. He's committed himself to the never-ending journey of understanding the intricacies of quality code, developer productivity, and job satisfaction.

Published Friday, October 08, 2021 7:30 AM by David Marshall
Filed under: ,
Comments
There are no comments for this post.
To post a comment, you must be a registered user. Registration is free and easy! Sign up now!
Calendar
<October 2021>
SuMoTuWeThFrSa
262728293012
3456789
10111213141516
17181920212223
24252627282930
31123456