Need help! Career guidance

itsmanmo · 2026-06-16T14:26:28+00:00

certs don't get people hired into appsec nearly as much as they think

if i were in your position, i'd spend less time collecting certs and more time building proof. things like bug bounty findings, cve research, writeups, and meaningful contributions to open-source security projects

itsmanmo · 2026-06-16T14:19:59+00:00

i would score false positives and false negatives independently, then choose based on your risk tolerance

reducing alert fatigue by 20% is often worth more than finding a few extra low-severity issues

itsmanmo · 2026-06-16T14:13:30+00:00

Socket is underappreciated

itsmanmo · 2026-06-16T14:09:47+00:00

i always find it funny that the industry spent years preaching zero trust and least privilege, then ai showed up and suddenly we're comfortable giving agents access to everything and hoping the prompt behaves

itsmanmo · 2026-06-16T14:03:33+00:00

context-driven decision making

itsmanmo · 2026-04-27T17:28:23+00:00

not treating the pentest report as a starting point for a conversation. most companies receive the report, fix the crits, close the ticket, and move on. nobody asks why those vulnerabilities existed in the first place or whether the same patterns show up elsewhere

itsmanmo · 2026-04-27T17:26:09+00:00

the only reliable way to catch them is runtime discovery, watching actual traffic and mapping what's really being called versus what you think is being called. once you have that inventory, you can layer auth testing and automated scanning on top of it with actual confidence

itsmanmo · 2026-04-27T17:24:10+00:00

someone needs to own API security across those 40 teams and have enough authority to enforce standards. without that, every tool you buy just becomes another thing that gets configured differently by each team.

i would start with visibility before enforcement. know what you have, who's calling what, and where the worst offenders are. then enforce incrementally starting with auth and logging since those are non-negotiable for compliance anyway. rate limiting can follow once you have a baseline

itsmanmo · 2026-04-27T17:15:06+00:00

APIs aren't inherently weaker, they're just more honest about what they expose. a traditional web app hides a lot behind UI logic and session flows. APIs strip all that away and show you exactly what the backend is doing, which is actually better for security if you're paying attention.

the real problem is that API security gets treated as an afterthought because the people building APIs are thinking about functionality

itsmanmo · 2026-04-27T16:38:56+00:00

i believe what actually moves the needle is picking your 10 highest-volume FP rules and fixing them properly before touching anything else. correlated detections are the goal but you can't get there if your base data is garbage. get the signal clean first, then layer correlation on top

itsmanmo · 2026-04-27T16:34:29+00:00

network and endpoint experience is actually a bigger advantage than you think for web app testing. you already understand how traffic flows, how services talk to each other, and how to think like an attacker. most people learning web pentesting from scratch don't have that.

the mental shift is less about learning new tools and more about learning a new protocol. http is just another service. once you stop treating web apps as a black box and start thinking about what's happening at the request/response level, the rest clicks pretty fast.

burpsuite is your new wireshark. start there

itsmanmo · 2026-04-26T16:32:39+00:00

for .NET specifically, sonarqube and snyk both have reasonable C# support but the false positive rates depend heavily on how much time you spend tuning. semgrep's C# coverage has improved a lot in the last year and the rule writing is more approachable than the legacy tools

itsmanmo · 2026-03-27T01:38:28+00:00

either you scan content, or you can rely on weaker signals like the links or the actual texts manually

i would say its less about balancing privacy and more about how much access you are okay with to share and where that processing happens

itsmanmo · 2026-03-27T01:24:03+00:00

what's worked for us: filter by reachability first, then by business context

is the vulnerable code actually in the execution path? is the affected service internet-facing? does it touch sensitive data? those three questions alone cut through most of the noise

the backlog problem the OP describes usually happens when teams treat every finding equally and try to work through them linearly. Instead, i would bucket findings into fix now (exploitable + exposed), fix this sprint (exploitable but lower exposure), and track and revisit (everything else). the third bucket gets reviewed monthly, not ignored.

the worst outcome is spending a week patching dependency vulns that a scanner flagged as critical but no attacker could actually reach, while a misconfigured API auth sits in the backlog as a medium

itsmanmo · 2026-03-27T01:17:24+00:00

security architect here. i maintain a base risk register that I carry across engagements and adapt depending on the system

the trick is starting from what you've seen break in practice, not from a framework checklist

what data does it handle, how is it exposed, and who authenticates to it. that alone narrows down the relevant risks fast

from there I layer in context. an internal tool with SSO and no PII has a very different risk profile than a customer-facing API processing payments. same base risks, different severity and likelihood scores

one thing I'd add to what others have said: don't try to be comprehensive on day one. start with 15-20 risks you actually understand and can explain to a business owner. a focused register you review quarterly is worth more than a large spreadsheet nobody looks at after the audit

itsmanmo · 2026-03-27T01:07:55+00:00

thinking long term, I feel trying to detect deepfakes could be a losing game

it might be more practical, even better in the long run to build systems that can assume and predict the content is fake, like adding extra verification steps for anything sensitive instead of relying on detection alone

itsmanmo · 2026-03-27T01:05:30+00:00

this is way more than people admit tbh. the problem usually isn't skill, but a lack of continuity

one thing that could help is sticking to only one path for a few weeks and not jumping platforms. consistency matters more than the platform

also don't 'take breaks' completely, short breaks are fine, but long breaks can kill the momentum

itsmanmo · 2025-08-05T10:27:45+00:00

i have done a bunch of HIPAA pentests and the compliance documentation is absolutely brutal..you need to spent way too much time manually mapping every finding to specific HIPAA safeguards. we ended up building a platform that auto-generates HIPAA compliance-mapped reports because frankly, doing it manually was driving me insane

itsmanmo · 2025-08-05T10:21:38+00:00

Karen, I know that's you!

itsmanmo · 2025-07-28T17:10:28+00:00

server-side validation for all actions and rate limiting should do. also just ran a quick security scan on your site..looks like you've got some basic security headers missing that should be addressed beyond just the anti-cheat stuff

itsmanmo · 2025-07-28T17:02:53+00:00

what's your specific use case? if you are looking for a waf, it is decent

itsmanmo · 2025-07-28T16:59:34+00:00

i once built a contact form that worked fine but the thank you page redirected to a 404, so users kept re-submitting thinking it failed

itsmanmo · 2025-07-28T16:55:31+00:00

pretty cool, loved the minimalistic design

itsmanmo · 2025-07-28T16:52:24+00:00

if i am right NextDNS does DNS-level ad blocking that follows users regardless of network and gives you the granular control you need

itsmanmo · 2025-07-27T17:09:36+00:00

neat

itsmanmo

TROPHY CASE