In today’s dynamic digital landscape, ensuring the security of your applications stands as a vital mission. Envision this: you’re a CISO, IT Security Manager, or a dedicated Product Owner, stepping into the spotlight of a security audit. The auditor’s inquisitive queries serve as an opportunity to enhance your security strategy, providing valuable insights into areas of improvement.
The auditor asks: “How do you monitor your app’s security posture?”
“We do penetration testing before any of our apps go into production. All findings are handled and fixed.”, you confidently respond.
“And how long ago was your last pentest?” the auditor follows.
How long indeed, you think. The app went into production about a year ago. Most of the old team moved into other projects after that, which worried you at first. But new features have rolled out regularly after that. “About a year ago,” you reply.
The auditor smiles and asks: “So, what is your app’s security posture now?”
You wince. “Uhh, our team is delivering a lot of value. No one hacked us if you mean something like that. Our developers are experts. They know OWASP,” you say and smile.
“Your team probably uses a dashboard for passing and failing builds. Don’t you have similar metrics for security?” the auditor asks.
You sink in your chair as you remember the Log4j chaos at your company. It took weeks to find which app used the library and which didn’t. There was a similar situation with another vulnerable library not so long ago. With both cases, everyone sighed in relief after the apps were patched. There was a brief lessons-learned discussion about the incidents, but everyone just patted each other on the back. You wondered if there was room for improvement but forgot the matter soon after.
“Let’s move on,” the auditor says. “How’s your quality control?”
“We have an ISO 9001 certificate,” you reply without hesitation.
“Yeah, great. What about code quality? Do you have static code analysis and reviews?”
You rub your face as you reminisce about the most recent horrible bug. A self-proclaimed white hat hacker found that every user could see every other users’ personal information in the app. All it took was opening some browser tool thing. Luckily the team fixed the bug before any real user noticed it. After that you contemplated instructing the team to cross-check each other’s work. Upper management would have shot that down for cost and inefficiency.
“Our developers are committed to producing high-quality code. We have a bonus plan”.
The auditor sighs. “How do you detect threats at early stages of development? Do you do threat modeling?”
“After a project starts, Security requests a spreadsheet about firewall openings the project might need,” you say. “But that’s not what you meant, isn’t it?”
“No,” the auditor says.
Getting DevSecOps
Have you had a similar conversation before? Are you wondering how to tackle these issues?
One solution is to build security in the software development pipeline. You might have heard about DevSecOps before but passed it by as another buzzword. What is it all about, and what does “shifting left” mean?
The typical software development process can be visualised as a cycle:
The problem is that this cycle doesn’t include security in any way. Thus security can be thought of as something that will be done later. And it is often done later, maybe as the last thing before going into production.
DevSecOps aims to change this process so that security becomes everyone’s business. Here’s what shifting left means: security is incorporated into every step of the DevOps cycle. This allows identifying and remediating security issues early, when the cost of fixing them is still low.
The DevOps cycle is complemented with security gates:
Empowering developers
Threat modeling enables the team to identify and remediate flaws already in the design phase.
Developers can use static analysis tools (DAST) tools to get immediate feedback on their code’s quality and security. In addition, DAST tools act as a quality gate to prevent the accumulation of technical debt.
Software composition analysis (SCA) tools detect publicly-known vulnerabilities in project dependencies. This prevents running vulnerable code on accident. Container scanning tools do the same, but for containers.
Dynamic application security testing (DAST) tools perform automated penetration tests against an application. This helps to catch severe vulnerabilities such as SQL injections early.
Secret detection prevents pushing credentials into a code repository. It also helps to detect secrets in the repository’s history.
That’s a lot of tools
Tools don’t solve problems by themselves. They need humans to tweak their configurations and react to their observations. Humans in this case are developers.
Developers are focused on creating value for the customer. Security work is seen as a support function that provides no intrinsic value. How to introduce security to development teams, then? A small security team doesn’t scale across dozens of developer teams.
The Security Champion (by OWASP) is a development team member that promotes security in their team. They also act as a single point of contact regarding security.
Together with DevSecOps engineers, the Security Champions aim to:
- Promote security best practices
- Onboard teams to security tools and processes
- Organise activities such as game days or CTF (capture the flag) events, especially attack/defence CTF can be an eye-opener
- Build a solid knowledge base of security guidance
Seeing the big picture
The previously mentioned tools solve the quality problem, but what about visibility? Is penetration testing still the only way? And is the product owner still limited to point-in-time snapshots of their app’s security posture?
We think that DevSecOps solves this as well.
Do your developers write buggy code? How many vulnerabilities do your app’s libraries have? Is your app vulnerable to cross-site scripting?
Answers to these questions and more can be inferred from data produced by the security tools now used by your teams.
The security data can be gathered into a traditional data lake or warehouse. A reporting dashboard can then be built to describe the security posture of your application(s) on multiple levels.
Senior management, not necessarily familiar with security terminology, can view a simple green-yellow-red security dashboard. Tech-savvier product owners can drill down to their own apps.
Key takeaways
- Fixing security issues early is cheap, expensive later
- Security is everyone’s business
- Everything isn’t solved by automation
- Security is measurable
Interested for more? Stay tuned for the next secure development blog post!
