DevSecOps Stating The Obvious - Part2

Previous part

I am still stating the obvious when it comes to DevSecOps 😄

Review your tools

Nowadays, it became super easy to add a new tool to your stack

Log in with Github and there you go, you have a tool for code quality coverage. Allow access to AWS and there you go you have a tool for billing analysis.

While those tools are really helpful, you should always ask yourself

  • Who are the creators of a certain tool, what is their reputation

I believe you should answer all of these questions before carrying on, because what if the code coverage tool you are using gets hacked and your code is taken, do you have something to worry about rather than your IP? Secrets and Keys for example?

What if your CI server is hacked, you Docker registry …etc?

Scanners FTW

No, I am not going to talk about the vulnerability scanners while they are useful what I want to talk about here is your own scanners looking for misconfigurations, we have the rules in place, the policy is written, but human error is inevitable, and I suggest having scanners running to detect any mistakes, for example, if no EC2 security group is allowed to go public you should have a scanner periodically checking if this rule is enforced or not

here is a dirty code to check that

apply the same concept for everything, scan for public docker images, IAM rules, and of course the root of all devils “public S3 buckets.”

Threat Detection

Recently Cado security released a report regarding the first crypto-mining worm to steal AWS credentials, we have seen this type of attack before when Tesla’s Kubernetes dashboard was hacked, and AWS got stolen, but it was a single attack, not a worm, read more here

Event threat detection products can help with such attacks by detecting mining traffic you can use products like

Watch for CVE lists and latest security updates

It’s really important that the team stays up to date regarding the latest CVEs

Of course, your code scanners we mentioned in part one can automatically detect some vulnerabilities but how about vulnerabilities in the tools themselves, for example, a vulnerability in Kubernetes or in Jenkins

Keep your eyes open for security updates, password dumps, new worms out there ..etc

Just like the Cado report above

Final thoughts

Security is an ongoing process, you should always review, enhance and repeat

Humans are important, and I am not talking about the typical weakest link thing, I am talking about not pissing the whole development team for a new policy, security is really important, but the whole point of DevSecOps is to integrate security in the process not to prevent people from working and slow down productivity.

If the development team is not happy with the security policies, then you have a problem with the policies themselves or the security, people can be pissed because they don’t understand why a certain policy in place, train them and try to be as transparent as possible.

NEVER do security only on paper, some organizations might just want a written down policies to pass an audit or something, never write something that you don’t do

“Write what you do, and do what you write”

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store