Author: C.J. May

Code review is an important part of the development process that can help to identify issues with the quality of the software. Secure code reviews are a specific type of code review that specifically evaluates the security of the software’s source code. Activities that don’t include the source code (like DAST tools and pen tests) are not considered “secure code review.”

Some of the steps in a secure code review can be assisted by automated tools, but many need a human for critical thinking and understanding of real-world processes. In this post, we will explore the different things you should do during a secure code review, point out which of those things can be automated, and then summarize everything into a cheat sheet for you to reference when performing your own secure code reviews!

About This Series

Last time, a cryptocurrency scammer scanned Android APKs on the Internet Archive and found thousands of leaked Twitter API keys. After that, the scammer invested money into an altcoin and used the leaked API keys to promote the altcoin with hijacked Twitter accounts. The story ended with a classic pump-and-dump that made the crypto scammer millions of dollars at the expense of duped investors.

In this series, we will dissect not just what an attacker can do to get access to credentials, but also what they would do after getting that initial access. We will walk through a different threat scenario in each part of the series and tell stories of malicious hackers that are either true, based on a true incident, or reasonably theoretical.

About This Series

Last time, a malicious hacker got access to Poor Corp’s internal git repositories and used an open-source secret scanner to find and steal AWS keys. Using the stolen keys, the hacker gained deep access to Poor Corp’s major SaaS services and stole all their customer data.

In this series, we will dissect not just what an attacker can do to get access to credentials, but also what they would do after getting that initial access. We will walk through a different threat scenario in each part of the series and tell stories of malicious hackers that are either true, based on a true incident, or reasonably theoretical.

About This Series

Last time, we covered a scenario in which a threat actor found leaked RSA private keys used by a TLS wildcard certificate for “Poor Corp.” By chaining the leaked private key with DNS misconfigurations, the attacker was able to impersonate a Poor Corp subdomain and use it to create highly effective phishing emails.

In this series, we will dissect not just what an attacker can do to get access to credentials, but also what they would do after getting that initial access. We will walk through a different threat scenario in each part of the series and tell stories of malicious hackers that are either true, based on a true incident, or reasonably theoretical.

If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. – Sun Tzu, “Art of War”

When you’re on the Blue Team, you’re expected to understand the systems you have to secure and the configurations to look out for. New vulnerabilities and attack paths are constantly being discovered, and it seems like there is an ever-growing list of things to not do wrong. Sometimes, though, we need to think beyond lists of vulnerabilities and put ourselves in the shoes of an attacker.

In this series, we will dissect not just what an attacker can do to get access to credentials, but also what they would do after getting that initial access. We will walk through a different threat scenario in each part of the series and tell stories of malicious hackers that are either true, based on a true incident, or reasonably theoretical.

This blog post is the second half of my research on making it easier to create Seccomp-BPF filters and secure your containers with them. If you haven’t read the first half of this blog post yet, I recommend doing so before continuing here.

For returning readers, I’ll briefly refresh you on my last post. I introduced Seccomp-BPF, which is a Linux kernel feature that allows you to create filters that restrict which syscalls a process can make. This allows you to prevent a process from being able to do something that it was not intended to do if it requires a new syscall. Seccomp-BPF filters can also be applied to container runtimes and orchestration tools to limit what your containers can do while they’re running. That allows you to add a layer of protection against the potential exploitation of your applications and services.