DEV Community: VickkyKruz NetSec

StackSentry Is Now Installable — And We Need You to Break It

VickkyKruz NetSec — Sat, 11 Apr 2026 04:08:12 +0000

Hi everyone 👋

I've spent the last several weeks detailing everything about StackSentry, how it works, what it scans, how it auto-fixes security issues, and what you can expect from it across different stacks. Now it's time for the most important part: I need you to test it and tell me what breaks.

🛡️ StackSentry v1.0.0 is officially live on PyPI.

In one command, it scanned my own VPS, auto-fixed six security issues via SSH, and took the security grade from F (16.7%) to C (72.7%) — with zero attack paths detected after fixes.

pip install stacksentry

I'm looking for testers across all stacks: Flask, Django, PHP, WordPress, shared hosting, VPS. If you have a web app running anywhere, run it, open issues, and tell me what's wrong. Your feedback at this stage is everything.

I've written up the full story, what it does, how it works, and the proof in my latest article. Go through it and share your thoughts: 👉 https://vickkykruzprogramming.dev/blog/stacksentry-is-now-installable-and-we-need-you-to-break-it

Also, the full project README is on GitHub, it can be access here: 👉 https://github.com/vickkykruz/stacksentry

⭐ on GitHub helps it reach more people. Thank you in advance.

DevOps #Security #Python #OpenSource #WebDev

Are AI Companies Monetising Our Desperation? My Honest Claude Experience

VickkyKruz NetSec — Wed, 08 Apr 2026 01:47:09 +0000

8 years as a software engineer. I've tried ChatGPT, DeepSeek, Perplexity and Claude felt the best.

But I kept hitting usage walls. So I wrote about it and the uncomfortable question it raised.

What do you think? Drop your thoughts below 👇

https://vickkykruzprogramming.dev/blog/are-ai-companies-monetising-our-desperation-my-honest-claude-experience

Your Cache Is Lying to You, Here's How to Reveal the Truth

VickkyKruz NetSec — Fri, 03 Apr 2026 12:38:14 +0000

Hello folks 👋

This is a topic that doesn't get discussed much in engineering communities: caching is probably one of the most hazardous implements in your toolset, not because setting it up correctly is difficult but because it is capable of failing silently, and the worst part is the timing of such failure.

There were instances when I saw production systems shut down simply because a cache key got expired at the wrong time. There were also moments when bugged pricing showed incorrect data to thousands of people throughout several minutes just because no one doubted the cache result. Distributed systems constituted another source of problem two users accessing the same endpoint getting two entirely different results simply because distinct instances maintained different cached data.

Such situations are not rare at all. They are recurring issues. And even the best engineers making these mistakes may be those who really know better in actuality.

Therefore, I decided to put together a comprehensive, research-supported exposition of the six most risky cache memory problems in sophisticated software illustrating each challenge with documented failure scenarios, runnable code snippets, and even the exact engineering tactics employed for their resolution.
👉 "Your Cache Is Lying to You: Here's How to Reveal the Truth"

https://vickkykruzprogramming.dev/blog/your-cache-is-lying-to-you-the-hidden-problems-of-cache-memory-in-complex-applications-and-the-engineering-discipline-to-fix-them

This article details the following: Cache Stampede · Cache Invalidation · Cache Penetration · Cache Avalanche · Distributed Inconsistency · Memory Pressure & Eviction

Featuring real-life case studies including how Facebook managed to reduce its peak database querying by 92% with just one caching tweak.
It would be great to get your perspective, have you ever encountered any caching issue that affected production? Why not share your experience with us here? Also, if this sort of hardcore engineering material is something you're interested in, consider hitting the follow button or subscribing.

SoftwareEngineering #SystemDesign #Caching #Redis #BackendDevelopment #TechBlog #Developer

From ATMs to WhatsApp: The Old Programming Languages Behind Your Everyday Tech

VickkyKruz NetSec — Wed, 01 Apr 2026 23:58:21 +0000

Hello👋 everyone

I was halfway through a thought when something hit me and stopped me dead in my tracks: the software running your ATM machine was coded even before your parents were born. The code forecasting the weather of tomorrow is older than the internet. The backend delivering your WhatsApp messages is built using a programming language that most developers have not even heard of.

We often discuss what the latest tech things are. Languages like #Python, #Rust, and #TypeScript, the shiny tools that everyone is learning. However, very few talk about the real factors that are holding all these up.

Hence, I followed a trail down the hole. I looked into 7 programming languages that the world had declared as old and no longer of use, and yet I discovered them quietly running global banking, space missions, aircraft avionics, and real-time communication of billions of people.

Here is the first piece of my blog:
👉 "From ATMs to WhatsApp: The Old Programming Languages Behind Your Everyday Tech"

https://vickkykruzprogramming.dev/blog/from-atms-to-whatsapp-the-old-programming-languages-behind-your-everyday-tech

It delves into COBOL, FORTRAN, Assembly, LISP, Erlang, Ada, and Prolog, complete with actual statistics, real companies, and the honest reasons why nobody has yet replaced them.

Let me know what you think, have you ever worked with any of these languages? Leave a message below and share your experience.

And if you like content that digs deeper than the headlines, don't hesitate to hit the follow or subscribe button. There's a lot more coming. 🙏

Programming #TechHistory #COBOL #SoftwareDevelopment #LegacyCode #Developer #TechBlog

One File. No Server. How I Built an Image That Talks Back.

VickkyKruz NetSec — Fri, 27 Mar 2026 11:19:28 +0000

Hello folks 👋

We've had a bunch of discussions about AI and computer vision, right? Still, today I'm bringing you something else, a little break. I am not revealing a gizmo I wielded but a thing I erected.

PhotoContour began with one riddle: what if a picture could chat with you?

We are talking about a single.svg that you open in any browser, move your mouse pointer over an photo object to see a popup with a label, a short text, and a link. No JavaScript. No dependencies. Just pure CSS.

This is an introduction to the secret behind it:
🔵 First YOLOv8 identifies all objects and extracts their exact contours.
🔵 Then FastAPI transforms these contour points into pixel locations and assembles the SVG.
🔵 React Studio facilitates you to select the object, add annotation, assign a color, and save.
🔵 The end product file is fully self-sufficient can be embedded in email, Twitter, LinkedIn, Discord, or any platform that can render SVG.

Speaking of bugs yes, there were bugs scattered. One was so cleverly disguised in a single variable name that it cost me a couple of hours figuring it out. The solution was one word.

I have done the entire build story the architecture", decisions, the" coordinate system gotcha, the" "accuracy problem that was actually a UX problem", and what's coming next.

📖 Full post here 👇
https://vickkykruzprogramming.dev/blog/one-file-no-server-how-i-built-an-image-that-talks-back

If you have ever desired to animate your pictures, this one might really be a treat for you!

OpenSource #Python #FastAPI #ComputerVision #SVG #React #SideProject #WebDevelopment #YOLOv8 #BuildInPublic

The Smarter the Tool, the Dumber We Become

VickkyKruz NetSec — Tue, 24 Mar 2026 22:02:13 +0000

Hey Dev.to community 👋

Just published a research-backed piece I've been thinking about for a while:

The Smarter the Tool, the Dumber We Become: AI and the Silent Erosion of Developer Skills

In it I cover:

The gradual dependency curve that's affecting junior and senior devs alike
What colonoscopy AI research and the Air France 447 crash have in common with your IDE copilot
The psychology of why over-reliance feels like productivity
A practical framework for using AI without letting it hollow out your fundamentals

It's not an anti-AI piece — I use these tools too. It's about using them with the same discipline a pilot brings to flying with autopilot on.

Would genuinely love to hear from this community — are you seeing skill erosion in yourself or your teams?

https://vickkykruzprogramming.dev/blog/the-smarter-the-tool-the-dumber-we-become-ai-and-the-silent-erosion-of-developer-skills

Tags: #ai #programming #career #discuss #productivity

Your AI Integration Is Probably Riskier Than You Think

VickkyKruz NetSec — Tue, 24 Mar 2026 07:37:43 +0000

Hello everyone 👋

It is no secret that we have talked about how AI is changing the tools and systems that we use and build, however, I thought I would share something a bit different today.

My recent blog post discusses a question that, in my opinion, is ignored most of the time: what do we really put at risk by including AI in our software?

Forget about the things out of a science fiction story. The factual, already-existing stuff.

Like the Samsung engineers who exposed confidential source code through ChatGPT accidentally.

Or the Amazon hiring algorithm that was silently penalising women applicants for years before anyone realized it.

Or the Air Canada chatbot, which gave a grieving passenger the wrong refund policy, and when the passenger asked for the refund, the airline even argued that the chatbot was a "separate legal entity" so that it wouldn't have to pay! (The court disagreed.)

I cover four risk areas in great detail, security, bias, privacy, and over-reliance, with real case studies and practical steps for each. It is intended to be understood by a reader who may be working in technology or simply using it.

Have you ever questioned the safety of the AI software that your company utilizes? Or maybe you are a student who is considering the use of AI? This article is definitely something you shouldn't miss.

🔗 https://vickkykruzprogramming.dev/blog/your-ai-integration-is-probably-riskier-than-you-think

It would be great if you could share your opinions through the comments section, have you experienced any of these risks in reality?

Manual security checks don't scale. Here's what we built instead.

VickkyKruz NetSec — Mon, 23 Mar 2026 02:40:18 +0000

Hello all

Being tired of scanners producing plain unordered lists of findings, I decided to make a Python CLI that does a security audit of Flask/Nginx/Docker/Linux stacks and includes 2 additional things I couldn't locate in other tools:

Cost-aware prioritisation

A failing check that is higher on the output needs to have higher priority. So that's why I use the following equation to assign a priority to each failing check:

priority = (severity_score × impact_weight) ÷ effort_score

If we consider a HIGH finding that is only one config flag, then it is scored higher than a HIGH finding that requires an architectural change. The result is a Task Day 1 / Day 7 / Day 30 ordered remediation plan.

What-if simulation

You (even) don't have to make changes if you only want to see the result of fixing a random subset of checks (you can simulate it):

python audit.py --simulate HOST-FW-001, APP-COOKIE-001

It will update your grade and attack-path count as if those checks passed. Automating roadmap simulation might look like:

|---|---|---|---|

| Current | F | 40.9% | 1 |

| Day 1 | D | 63.6% | 1 |

| Day 7 | C | 78.2% | 0 |

| Day 30 | A | 95.0% | 0 |

There is also a --profile option (student / devops / cto) that changes the language to OWASP narrative that suits different levels of understanding without altering the list of findings.

24+ checks, OWASP Top 10:2025 mapped, ReportLab PDF generation.

No paywall articles: https://vickkykruzprogramming.dev/blog/manual-web-app-security-checks-don-t-scale-inside-our-automated-assessment-remediation-framework

GitHub: https://github.com/vickkykruz/sec_audit_framework

I will be glad to explain the scoring model or attack-path detection logic.