From "vibe coding" to real shift-left: what I learned building my own event's platform with Kiro

This past Saturday I had the chance to give a talk at Expomaqser, held at Universidad Católica Santiago de Guayaquil. I built the talk around the creation of the platform for the AWS Security Day event I organized back in July 2026. The whole platform, from the main portal to every resource on it, sponsor forms, the attendee registration site, an admin panel, all of it was built with Kiro IDE, using the Claude Sonnet model. What made it interesting was that I opened by saying that something had found a vulnerability along the way, because I wanted to make a point clear: using AI to build code or entire platforms has to include security reviews from the very start.

To show that in the talk I used this same project as a real example, with three layers of review working at different points in development.

In the editor, an Agent Hook in Kiro runs Checkov before every push. Right there, on my own machine, I find out about a problem in seconds, before that code ever reaches a repository.

In the Pull Request, Checkov and Semgrep act as a blocking gate over the Terraform and the Python code for the Lambdas. At the same time, the AWS Security Agent reads the full diff of the change and flags things a pattern scanner misses, like attack chains or business logic that crosses several files. I had a real case in one of the project's PRs where both technical checks passed clean, and the Security Agent still flagged a high finding: the anti-bot protection had been removed from a registration endpoint, and no automated check caught it.

Once the system was deployed, I ran threat modeling with STRIDE and several rounds of pentesting. The threat model surfaced 21 possible threats before they became a real problem. And it was actually a full code review, done once the platform was already in production, that found the finding I mentioned at the start of the talk: a sensitive captcha key stored as a plaintext environment variable in a Lambda function, visible to anyone with basic read access to it.

For the pentest side, I ran four rounds against the same production system. The second round turned up a high-severity finding. By the third round, that finding was gone. The fourth round confirmed it stayed fixed. That, to me, is proof that these layers don't just catch problems, you can actually confirm with real data that what gets fixed stays fixed.

I based this talk on what I learned in the AWS New Voices sessions, where the idea was to hook the audience and make sure they walked away with something from the session. My goal was for them to take away the part about adding security into every phase of software development.

It was genuinely rewarding for me to see the attendees seeing how, using AWS tools, you can build solutions and expose them to the internet securely.

You can find the streaming here https://www.youtube.com/watch?v=vQ31PIyM3Yc&t=7732s