Security is a Broad Concept
When engineers, especially developers working with modern cloud environments and technologies, mention “security,” it can mean both everything and nothing at the same time. Security can range from the office firewall to user tokens when reaching the API. It encompasses user permissions within a cloud environment and application permissions when running inside a container within a cluster.
So, where should the focus be? Which areas can be “outsourced”? And, should you even care?
Let’s take a step back:
What is DevOps Again?
Without reiterating the same old mantra, I’ll sum it up in one go: DevOps is not a job title or an engineering field. It’s a culture, a collection of technologies, and most importantly, a specific way of doing things with the goal of improving the development life cycle. While this explanation may seem generic, it’s a testament to the term’s overuse and varied interpretations over the years.
Who Needs to Worry About Security?
The answer is simple: all engineers. But worry how, you may ask. Well, HACK!
Web Developer? Learn how to scan the /dist directory and JS files. Understand the mechanisms behind authentication, keys, tokens, and cookies. Learn the different headers and types of requests that come in and leave the application. Backend Developer? Are you aware of IDORs? Do you know what they are? Is there a chance you’re vulnerable? There are too many vulnerabilities to cover in one go, but it’s essential to stay updated with the latest news and discoveries. Familiarize yourself with OWASP and their Top Ten list of hot vulnerabilities. Although OWASP focuses on web applications, this knowledge is relevant across all areas. Every app, deployed in any environment, is susceptible to some attack vector.
Best way to avoid vulnerabilities? That’s right, NO CODE 😉
Why it Matters
When it comes to security, it’s challenging to go overboard. While that’s an option, merely proposing the idea that all developers are involved in the process—from development through QA to Ops and Sec—broadens the pairs of eyes looking at the code, infrastructure, and bugs. No one is free of responsibility, and the more, the merrier.
Take SQL injection, for example. It’s a vulnerability every engineer should at least be able to explain during an interview. SQL injection can be found and blocked at many levels, from the code susceptible to query injections, through the QA process that can test for simple scenarios, to automated services that check for these vulnerabilities in CI. Additionally, infrastructure systems like a WAF can block suspicious queries with filters that identify malicious injections.
When is it Important?
Security is one of those things that’s easy to ignore, overlook, or get frustrated with, and for a good reason. Rotating your Google password every other Tuesday is annoying and unhelpful, but having your entire production authentication secret keys leaked in your JS files can be the end of an organization (don’t ask how I know).
“The primary reason security professionals advise against periodic password changes is that when human beings change passwords often, they tend to conform to a pattern. That is why ethical hackers at Packetlabs see passwords like Summer2021, Fall2021, Spring2021.” - Packetlabs
Things to Consider
Most engineers won’t naturally dive into the world of ethical hacking or bug bounty programs. It takes education and continuous growth. Much like code reviews or DevOps education, application security is part of that growth.
Most security teams and CISOs might ask you to rotate your password or use Chrome instead of your beloved Firefox. They might not check if the app is vulnerable to an RCE because the file uploading feature lacks basic scanning. This is unfortunate but often the reality.
Nobody knows everything. Understanding this is key. With that in mind, a team can start thinking about the right way to build a system to improve security. One great option is the system of guilds, where an engineer can be part of the “web app security” guild and meet once a week to discuss concepts, tools, or methodologies. There can be multiple guilds: one for QA, another for developers, and a third for ops engineers. As long as the team is aware and actively working to improve, changes will compound over time, hopefully preventing the next disaster from occurring.
Conclusion
Sharpen your axe and stay vigilant. Security is a continuous process that involves everyone in the development lifecycle. By fostering a culture of awareness and proactive measures, we can collectively enhance our systems’ security and resilience.
