Mocking – something we all need, and yet, usually, hate. Simply because writing mocks is a boring and cumbersome task. The good news – it doesn’t have to be like that. There are so many good alternatives that make mocking easier: From libraries that ease the process of writing the mock, though contract testing with Pact (which solve the problem in a totally different way) to automatically generating mocks using Swagger/Open API spec. All are really good solutions – but today I want to focus on WireMock: A tool that really makes mocking a fun.
Infrastructure-as-code (and GitOps) extend the use of source control (git) and code (well, manifest files) into a new field. This changed radically how we create infrastructure in the cloud, by making the process more robust and less error prone, and also easier for developers. Can we do the same for threat modeling? How can threat-modeling-as-code change and improve the way we do threat modeling today?
Let’s start with a really short introduction to threat modeling. Threat modeling is a practice that help us take a system design and look for possible security issues, by asking these 4 questions:
- What are we building?
- What can go wrong?
- What are we doing about it?
- Are we doing a good job?
Conduction a threat model helps to find issues sooner – and in most cases, detect issues that are hard to find using other practices. This is why conducting a threat model is a critical part in building a secre software. If you’re not familiar with this practice, I’m highly recommending this post by Adam Shostack, one of the authorities in the field. OWASP Threat Modeling project (and channel) is also an excellent learning resource.
In the last two weeks, I was working on releasing the first OSS release of Kamus, a secret management solution for Kubernetes. To release Kamus, I had to publish a few docker images to Docker Hub and the CLI – which is deployed as an NPM package. This was the first time I had to deal with deploying packages to a repository. Doing this process thought made me thinks a lot about the (in)security of this process, and I want to share these thoughts with you. It’s all sums up to one small question – what’s inside the box? Do you know what you install when you download a package from a repository?
Every DevSecOps engineer will recommend you to start using security tests. I personally just blogged about it recently – if you’re not familiar with the concept, I’ll highly encourage you to read it first. It’s sound right, but there is one important question: Can we find real exploits using security tests? Can we pwn a web application by scanning it for security issues?
The best way to find out is to take a real broken web application, scan it with various security tests and look for exploits we can use. Today victim is OWASP Juice Shop, a very famous vulnerable web application, written using NodeJS and Angular. Let’s try to hack it, the DevSecOps way!
Today, I looked at our production Kubernetes cluster dashboard and I noticed something weird:
Well, this looks pretty bad. This is the average disk usage of the nodes running in the cluster. On average, only 20% percent of the disk in each node is available. This is probably not a good sign.
As you might already notice, my new blog is powered by WordPress. When I chose to start a new blog and run it WordPress, I started to look on WordPress security. There are already great posts about improving the security of your WordPress site (see for example this and this guides). There are also many posts describing various security plugins you should be installing.
All this information is critical – but it’s not enough. What about elementary web security practices? For example, leveraging security headers to protect your site? Or enabling
security.txt so good hackers will know how to contact you, in case they find a vulnerability in your site?
I like to write code. I’m doing it a lot, both professionally and for fun. Still, writing a good code is a challenge. Writing a code that is working, maintainable and secure is very hard to achieve. This is why we need automation – to spot the issues we missed. Tools like unit tests, code coverage or security tests can help detect various issues and help us write a better code.
Let’s take an example. I’ve created a small sample app using .NET core, my favorite language. I also created one container so we have something to play with.
Now it’s time to ask – does this code has security issues? Can I publish it to production?
You can try to answer this question by reading the code, or read along and learn what tools you can start using today to spot these issues. Continue reading “Want to Write Good Code? Start Using Security Tests”