I Tried to Hack My Own PaaS... Here's What I Found (HYNA-Stage v2.5.0 Security Audit) ππͺ
Harun - solo dev on November 08, 2026
Happy Diwali, everyone! πͺ
I just got back from blasting firecrackers with my brother, grandpa, and cousins. My ears are still ringing, my fingers ...
20+ years of coding experience across video games, logistics, finance, real estate, and legal/law industries. I'm a versatile, abstract-thinking solver of problems across many domains and disciplines
It's great to see you're thinking about security so "early" in your build! I'd caution against thinking anything is ever "bulletproof". There will always, always, be vulnerabilities in every system. It's a balancing act between the potential cost of the security risk and cost to fix. Some things really aren't worth trying to fix over others.
This sounds like a great start towards securing things as much as possible. It's awesome to see another founder considering the "uglier" or "less glamorous" side of building. π
A self-audit has a structural blind spot: you test against the checklist you already have. Anything outside the categories you thought to write down never gets probed, so "no findings" can mean "the audit is healthy" or "the audit can't see anymore" β and the report looks identical.
One way to tell which is which: keep two or three known-low-severity issues in the backlog on purpose, seeded across different categories, and treat the audit's failure to surface a seeded issue as a finding about the audit itself. If a real bug gets reported externally while a seed in the same category stayed silent, your pipeline has gone blind in that area.
It turns the audit from a gate into a detector with a test signal.
Nan, this is an incredibly sharp and valuable insight. Thank you for taking the time to share this.
You are absolutely right about the structural blind spot of self-audits. It is entirely possible for an audit to return "clean" simply because the testing framework isn't looking in the right places, rather than because the system is actually secure.
Your suggestion of seeding known, low-severity issues across different categories to test the audit pipeline itself is brilliant. It essentially turns the audit from a static checklist into an active, self-validating detector (similar to Chaos Engineering or Canary tokens).
I am adding this concept directly to my security roadmap. For the next audit cycle, I will intentionally seed a few controlled, harmless "vulnerabilities" (like a dummy exposed variable or a mocked RLS bypass) to verify that the automated checks and manual review processes actually catch them.
Thank you for pushing me to think beyond the checklist. This is exactly the kind of rigorous, adversarial thinking that makes a platform truly production-ready. ππ
13. Building ForkCount (forkcount.github.io) β a free calorie tracker that won't let you set a target below your BMR. CMO at HYNAWEB. Fixing bugs, writing posts, banning phishing bots.
Location
France but not french
Education
Homeschooled. Learning to build software by shipping and breaking things.
Pronouns
he/him
Work
Building ForkCount. 13. Not a company β just one person and a lot of AI prompts.
13. Building ForkCount (forkcount.github.io) β a free calorie tracker that won't let you set a target below your BMR. CMO at HYNAWEB. Fixing bugs, writing posts, banning phishing bots.
Location
France but not french
Education
Homeschooled. Learning to build software by shipping and breaking things.
Pronouns
he/him
Work
Building ForkCount. 13. Not a company β just one person and a lot of AI prompts.
13. Building ForkCount (forkcount.github.io) β a free calorie tracker that won't let you set a target below your BMR. CMO at HYNAWEB. Fixing bugs, writing posts, banning phishing bots.
Location
France but not french
Education
Homeschooled. Learning to build software by shipping and breaking things.
Pronouns
he/him
Work
Building ForkCount. 13. Not a company β just one person and a lot of AI prompts.
It's great to see you're thinking about security so "early" in your build! I'd caution against thinking anything is ever "bulletproof". There will always, always, be vulnerabilities in every system. It's a balancing act between the potential cost of the security risk and cost to fix. Some things really aren't worth trying to fix over others.
This sounds like a great start towards securing things as much as possible. It's awesome to see another founder considering the "uglier" or "less glamorous" side of building. π
A self-audit has a structural blind spot: you test against the checklist you already have. Anything outside the categories you thought to write down never gets probed, so "no findings" can mean "the audit is healthy" or "the audit can't see anymore" β and the report looks identical.
One way to tell which is which: keep two or three known-low-severity issues in the backlog on purpose, seeded across different categories, and treat the audit's failure to surface a seeded issue as a finding about the audit itself. If a real bug gets reported externally while a seed in the same category stayed silent, your pipeline has gone blind in that area.
It turns the audit from a gate into a detector with a test signal.
Nan, this is an incredibly sharp and valuable insight. Thank you for taking the time to share this.
You are absolutely right about the structural blind spot of self-audits. It is entirely possible for an audit to return "clean" simply because the testing framework isn't looking in the right places, rather than because the system is actually secure.
Your suggestion of seeding known, low-severity issues across different categories to test the audit pipeline itself is brilliant. It essentially turns the audit from a static checklist into an active, self-validating detector (similar to Chaos Engineering or Canary tokens).
I am adding this concept directly to my security roadmap. For the next audit cycle, I will intentionally seed a few controlled, harmless "vulnerabilities" (like a dummy exposed variable or a mocked RLS bypass) to verify that the automated checks and manual review processes actually catch them.
Thank you for pushing me to think beyond the checklist. This is exactly the kind of rigorous, adversarial thinking that makes a platform truly production-ready. ππ
@effessdev bro what do you think π€―
Bro any updates regarding the call?
Not yet
Any updates now?
No bro these guys are frustrating
@forkcount bro whats the progress on the 5 users
Didn't you get my email from 2 days ago?
Nooo
Hmmm? Didn't I tell you I will do it but different. TALK BY EMAIL PLEASE
@akhourianmolkumar bro?
Great job, your own security tester.
BROOO THANKS AND BRO SORRY BUT POST DIWALI WISHES β€βπ₯β€βπ₯π€£π€£π€£
Happy Diwali β€οΈπ