I've been with my new company for a little over 2 months now. I joined at the end of April as an SWE II (go me π₯Ήπ). A few weeks into joining, I saw a post on Slack that our next Women in Tech mentorship cohort was starting. Being brand new, I of course, didnβt hesitate to jump at the opportunity.
When I signed up, I was determined to get matched with a mentor strong in system design and architectural thinking. What I got instead was an AppSec engineer β and just being honest, my initial reaction was disappointment. System design felt like the move, the natural next step for a fresh intermediate engineer trying to broaden her technical foundation. I knew security was important, of course, but it hadn't felt like the most critical thing for me to be learning right now.
Two sessions in, I'm still very much a beginner so I hesitated to write this post just yet β but I'm truly already feeling like this pairing has been invaluable. It's changing how I think about the code I ship every day, and I hadn't realized how big of a gap this was in my thinking until someone sat me down and started walking me through it. I'm sharing my learnings here in case you're like me β an engineer who never really considered cybersecurity as something that fell into your lane.
What even is cybersecurity?
At a high level I knew what cybersecurity was β or at least I thought I did. My mentor opened our first session with a simple framing: cybersecurity exists to protect networks, devices, and data from unauthorized access β because unauthorized access leads to fraud, criminal activity, and loss of trust. At a smaller fintech company especially, that trust is everything β it's not something we can afford to lose. Cybersecurity breaches affect real businesses and real money, and if we lose that confidence with our customers, weβre, for a lack of a better term, SOL.
The whole field is built on three central pillars, called the CIA triad:
- Confidentiality β data should only be accessible to people who are authorized to see it
- Integrity β data shouldn't be modifiable without authorization
- Availability β access to resources is controlled; you get what you need, not everything
The tricky part is translating those three ideals into how an actual engineering organization operates, which is exactly where different security teams come in.
Blue teams, Red teams, and everything in between
Security teams are typically broken into a few distinct groups β and yeah, they really do go by colours.
Defensive security (blue team) is focused on protection and detection, and there are a few subgroups:
- SOC (Security Operations Center) β monitors all company activity and flags suspicious behaviour. Why is someone from HR accessing an AWS server at 2am? The SOC catches that.
- Incident Response β steps in when something alarming is confirmed. This is notably different from engineering incident response and something I found pretty cool: you can't just fix it and move on. You have to preserve evidence and chain of custody for potential forensics β treat it more like a crime scene than a bug. You might even tell people not to restart their computers because the data in memory could matter later.
- Threat Hunting β proactively digs through existing logs to understand what could have happened if a known vulnerability had been exploited. Sometimes in doing that exercise, they uncover incidents that were actually real.
Offensive security (red team) flips the script β instead of defending, you're simulating what an attacker would do. The main approaches are:
- Penetration Testing β actively attempting to find and exploit vulnerabilities before a real attacker does. There are three types: black box (no prior knowledge), grey box (some knowledge), and white box (full knowledge of the system). This is what most fintechs focus on.
- Red Teaming β a full 360-degree security assessment that goes beyond the application to include physical access, social engineering, even impersonating employees to see if you can get into a building. This is much broader in scope, but also more expensive and less common.
There can also be a purple team, which is a hybrid of blue and red. It tests both security controls and defending against them at the same time.
Where AppSec fits in (and where it doesn't)
AppSec doesn't neatly slot into blue or red. It's a combination of both, but with a very specific focus: protecting the product, not the company as a whole.
If someone's laptop gets stolen, that's an enterprise security concern which is important, but itβs not AppSec's domain. AppSec is all about securing the application and its users (think: protecting a product that real businesses use to manage their money).
What I found really surprising is how much tooling quietly exists in the background to support this. Some of it was already running quietly in my own daily workflows β I just never knew what it was actually doing.
- SAST (Static Application Security Testing) β scans code for known vulnerability patterns
- SCA (Software Composition Analysis) β checks runtime dependencies for known malware or vulnerabilities; this can be run on most pull requests via Datadog
- Sonatype β acts as a package firewall, blocking downloads of suspicious or low-confidence packages to guard against supply chain attacks
There can also be custom in-house tools β for example a bot that scans all the links on a companyβs marketing directory page to check whether domains are still valid and not about to expire. This is important because an expired domain can be bought by an attacker and used for phishing or social engineering. I genuinely had no idea that this was even a threat vector before this.
What ultimately stuck with me - "100% secure doesn't exist"
My mentor closed our first session with something I keep coming back to: perfect security is an unobtainable illusion. Chasing 100% security leads to hyper-rigidity, and that level of rigidity doesn't belong in an environment that prioritizes shipping fast to serve customers. We have to balance shipping features quickly with shipping them securely β and the way you do that is through layered controls. If we can implement enough guardrails that an attacker has to work really hard to get anywhere, and if they do gain access somewhere they shouldn't, it's limited in scope and impact β then we've done the best we can.
A genuinely mind-blowing example of why this mindset matters is the Target breach of 2013 (something I'd never heard of before this). Hackers didn't break into Target's systems directly. They compromised the network of an HVAC company that serviced Target's physical stores, then pivoted from there into Target's internal infrastructure, eventually reaching point-of-sale systems. The result: 40 million credit and debit card numbers stolen, 70 million customer records compromised, an $18.5 million settlement, and over $200 million in estimated total losses β driven by damaged customer trust and a tanking share price.
It's not enough to trust that your third-party integrations are secured β never assume someone else has it covered. The HVAC vendor's network wasn't Target's problem β until it very much was, and by then it was far too late.
How an AppSec mindset is starting to change things for me
I came into this mentorship wanting to think bigger about system design. What I didn't expect was that AppSec would make me think more carefully about the systems I'm already building.
The thing my mentor kept highlighting is that AppSec at our company isn't a blocker. The team won't hold up a feature over a security concern β they'll flag it, provide recommendations, and work within the reality that the business needs to move fast. But, honestly that's actually all the more reason for engineers to be thinking about this, not less. If AppSec is a collaborator rather than a gatekeeper, the security mindset has to live somewhere β and a big part of that somewhere is the people planning projects and writing the code.
I didn't know I needed to learn any of this quite yet. Two sessions in, I'm really glad I accidentally did.
Disclaimer: This post was written with the help of AI (Claude Sonnet 4.6), but all thoughts, opinions, and experiences are my own and have been reviewed and edited by me.
Top comments (0)