This week I am handing part of the newsletter over!
Sharkybyte writes Cyber Bytes:
Covering the news, startups and the career side of security. They sent me five questions about cloud sec that come up constantly, and I sent five back about AI and startup security.
Enjoy ⬇️
1: What’s different about doing security at a startup vs a big enterprise?
The infra was the main learning curve for me, startups are small, there’s not that much infrastructure to dig through or technical debt yet. Breaking something doesn’t set off a giant domino reaction.
When I did ethical hacking for YC companies there was like a max of 10 domains, if you look at bug bounties for these massive orgs you’re gonna have like 1k minimum. It feels like this impossible onion sometimes
My current job puts me in a nice in between though working at a mid size company, which is super cool because you get to watch that infra get built up!
2: How do you review code you didn’t 100% write?
Well im not a SWE, so i have faith in the engineers that review my PRs. BUT i do make sure when i build something i keep in mind the structure of where data will be stored, how and the tool will work and instruct the agent accordingly and test the tool before pushing to production or publishing :)
3: Do small teams need a SOC, or is that mostly vendors trying to sell products?
Hmm okay, I think how we define a soc traditionally is changing now with AI. The AI native company has agents doing a chunk is not a lot of the base operations an analyst may traditionally do and I think we’re heading in the direction of AI being able to self improve on detections, alerting etc.
I do think rn theres a lot f snake oil out there, and no a 2 person team doesnt need a soc, BUT i do think there’s benefit in startups to have some sort of SIEM or Detection rules set up that an engineer and team of agents can monitor
4: Are AI coding tools creating more vulnerabilities or catching more of them?
I think it depends whos using them and which ones, but the models hae gotten MUCH better at coding, its one of the skills that has really been focused on nailing so i dont think id say theyre introducing more vulns than a human
HOWEVER, the caveat there is who’s using them, which ones and for what
If youre using a 2024 model, then yeah those such compared to like fable or astra
Also agents will do what you ask, for a non technical user, they may not know how to prompt to get the job done when it comes to coding vs an engineer who does
So the subsequent code is more likely to be buggy and insecure, but not because the skill of the agent is lacking but actually because it did exactly what you asked for
5: How did you get into appsec and would that route still work today?
So i got into security after watching the imitation game and getting into crypto which led to CTFs and a lot of late nights googling things
Eventually i ended up in college for cs, and interned in IT, vuln management and now as a SOC analyst :)
Cyber Notes | W J Pearce
1: What makes cloud security different from, say, security engineering?
I think they’re actually two very similar roles, and in a lot of organisations the titles are used interchangeably. Just because you’re called a security engineer in one organisation doesn’t mean you won’t be doing what another organisation calls cloud security engineering.
The way I think about the distinction is that they tend to come from slightly different backgrounds.
A security engineer is essentially someone with a strong security background who has also developed strong engineering skills. They might come from SOC, incident response, or forensics, but they’re also comfortable building and maintaining infrastructure, automating security controls, working with IAM, configuring firewalls, and scripting.
A cloud security engineer, on the other hand, is often someone who comes from a cloud engineering or DevOps background and has developed a particular focus on security. So you’re still working with CI/CD pipelines, Docker, Linux, Terraform, and cloud infrastructure, but you’re looking at those technologies through a security lens, things like cloud architecture reviews, IAM, workload security, and securing the deployment process.
So, for me, the biggest difference is less about the job title and more about where your engineering and security foundations come from. There’s obviously a lot of overlap between the two.
2: How do you see cloud security change with AI + cloud hosted agents?
I think there are probably two big ways cloud security is going to change with AI and cloud hosted agents.
The first is that there’s going to be a whole new skill set around securing these environments. We need to think about how we configure the infrastructure around agents, what guardrails we put in place, who can access them, and, perhaps most importantly, what resources those agents are actually allowed to access.
And then there’s the more traditional AI security side: protecting the models themselves from things like prompt injection, data poisoning, and model manipulation.
So there’s really a distinction between securing the infrastructure and permissions around the agent, and securing the model and its behaviour.
But I also think there’s a really interesting opportunity for cloud security engineers here, because these agents are going to become incredibly powerful engineering tools. I think we’ll move away from manually writing every Terraform module or configuring every piece of infrastructure ourselves. Instead, we’ll have agents that understand our environment and can make those changes for us.
And that actually creates another interesting security problem: how do you give an agent enough access to be useful without giving it enough access to do something catastrophic?
That means things like agent identity, least privilege access, strong observability, and potentially human approval for higher risk actions are going to become increasingly important.
So I think AI is going to change cloud security in two directions at the same time. It gives us a new class of systems that we need to secure, but it also gives us incredibly powerful tools for doing security engineering ourselves.
3: Whats an underrated technology in cloud you think more people should learn
This is probably going to sound a little controversial, because there’s been some pushback against it, but I think vibe coding your own productivity applications is massively underrated.
Even if they’re just small tools that you run locally and never actually publish, I’ve found that a lot of my processes as a cloud security engineer can be sped up or optimised by building these kinds of applications for myself.
For example, I’ve built little triaging tools that help me get to the root cause of an issue faster, or tools that make interacting with AWS much simpler. They don’t necessarily need to be production grade applications. They just need to solve a problem that I have.
And I think that’s particularly interesting for people who aren’t traditional programmers. I’m definitely not a programmer. I can script, I understand the fundamentals of programming, and I’m comfortable configuring scripts and environments to do different things, but I wouldn’t consider myself a software engineer.
The fact that tools like Claude Code and Codex can now help you build these applications with relatively little development experience is incredibly powerful.
I think they’re still massively underutilised, particularly within security. There’s sometimes a bit of pushback against vibe coding in the security community, and obviously there are legitimate concerns when you’re building production systems. But for small, personal productivity tools, I think there’s a huge amount of value there.
You can essentially build your own little internal tools to remove repetitive work, and I think more cloud security engineers should take advantage of that.
4: Do cloud security principles apply across providers, or should you focus on mastering one?
I’ll keep it short. Yes, the core security principles apply across every major cloud provider, but if you’re just getting started, I’d focus on mastering one first.
There are definitely jobs where you’re expected to understand two or more cloud environments, and a lot of companies have multi cloud setups. They might have their production environment on one provider and other workloads or backups on another.
Don’t overwhelm yourself with that when you’re starting out. Pick one cloud provider, learn it really well, and then you’ll find that a lot of the underlying security principles transfer across to the others.
I’m really comfortable with AWS at this point in my career, but I know embarrassingly little about Azure. So take that for what you will.
5: How did you get into cloud security?
I consider myself really, really lucky with how I got into cloud security. It was a bit of a right place, right time situation.
I was one of those people who, pre COVID, did a boot camp, landed a cloud engineering job fairly quickly, took an interest in security, found a mentor, and then just started skilling up.
I spent a lot of time learning in the evenings. I didn’t have kids at the time, and life was a little quieter, so I was able to spend a lot of my free time working and studying. I was basically working during the day and then studying in the evenings, and I did that consistently for a long time.
For anyone getting started in their career, I think that’s still the approach I’d recommend. You have to be willing to put in the work outside of your job and continuously develop your skills. Unfortunately, I think that’s more important now than it’s ever been.
That said, I also recognise that the landscape has changed. It’s not as simple as doing a quick boot camp and landing a job anymore.
I do think there’s still a lot of value in joining a training academy or structured programme, but I wouldn’t treat one as a guarantee of employment. Ultimately, you need to build the skills, get practical experience wherever you can, find people who can mentor you, and keep putting the work in.
I was very fortunate with the timing when I got started, and I think that’s worth acknowledging.
and follow sharkybyte here