The Scan I Barely Understood

At some point in building Beads of Hope T1D, the site started feeling less like a cute project and more like a real thing people might actually use.

That sounds exciting, and it was. But it also meant I had to face parts of the process I would happily have skipped if this were just a pretend store.

One of those parts was security.

I remember looking at a scan that flagged 9 issues and feeling my stomach drop a little. Not because I fully understood what any of them meant. Honestly, I probably understood about 40% of it. Maybe less, depending on how generous I’m being with myself.

The report had phrases that sounded like they belonged in a spy movie or a courtroom.

“Guest cart hijacking.”

That one got my attention. I pictured someone in a black hoodie stealing bracelets out of a shopping cart, which I realize is not exactly how the internet works. The plain-English version was more like: someone might be able to write to a cart that wasn’t theirs. Still not great.

Then there was “client-controlled unit price.”

This one made me pause. From what I gathered, it meant a customer could technically send their own price to the checkout function. In normal-person language: someone might be able to say, “Actually, this bracelet is one cent,” and the system might believe them if it wasn’t protected properly.

That was the moment I sat up a little straighter.

I’m building this site for Type 1 Diabetes awareness, and because of my son. He was diagnosed when he was two. The products are handmade. The point is hope and giving and community. But that doesn’t mean I can ignore the boring grown-up parts. If people are going to trust the site with orders, payments, and information, I need to take that seriously.

The third term that made my eyes glaze over was “RLS policies too loose.”

The AI explained that RLS means row-level security, which is basically a set of database rules deciding who can read or change what. A database is where the site stores things like products, orders, carts, and users. So “too loose” sounded like leaving the side door open and hoping nobody noticed.

I did not suddenly become a security expert that day.

What I did become was a person asking better questions.

I asked the AI what each issue meant in regular language. I paid attention to whether the explanation made sense, even if I didn’t understand every technical detail. I wanted to know: could this affect a customer, an order, a price, or private information?

If the answer was yes, I treated it as important.

Then came the strange part: deciding whether to trust the AI’s fixes.

Because here’s the honest truth. I couldn’t personally inspect the code and say, “Ah yes, excellent security work.” That is not my skill set. I’m 50, I don’t have a coding background, and half the time I still feel like I’m holding the map upside down.

So I trusted the process more than my own technical confidence.

The AI fixed the issues, then re-ran the scan. That mattered to me. It wasn’t just saying, “All better!” and expecting me to move on. The scanner checked again, and the issues were cleared.

Was I still a little uneasy? Absolutely.

There is something very humbling about building with AI. It can move so fast that you feel powerful one minute and completely out of your depth the next. One day I’m adjusting a blue ribbon graphic down a quarter inch. The next day I’m reading about cart hijacking like I’m supposed to know what that means.

I didn’t pretend to fully understand it. Not to myself, anyway.

But I also didn’t run from it. I slowed down, asked for plain English, looked for the real-world risk, and made sure the scan was run again after the fixes.

That may not be glamorous, but it felt like part of becoming responsible for the thing I was building.

What I learned: if I don’t understand the scary words, I can still ask what they mean, why they matter, and whether they were actually fixed.