Denver likes a good origin story. The city still keeps a marker for Louis Ballast and the Humpty Dumpty Barrel, the local spot tied to the cheeseburger's Colorado claim. That detail felt oddly right for SnowFROC 2026. A cheeseburger is a small upgrade that changes the whole meal. This year's conference kept returning to the same ideas in AppSec, such as how meaningful security progress often comes from well-placed layers that make the better choice easier to make.

The Snow in "SnowFROC" is due to the time of year the event takes place and the good possibility that it will snow, which it did this year. The other half of the name stands for Front Range OWASP Conference. This year, they expanded it into a two-day event in Denver that drew about 400 attendees to see 35 sessions, take part in 8 half-day training sessions, a CTF, and multiple village activities. The room carried that blend of practical curiosity and sharp hallway conversation that makes any security conference worth the trip.

Throughout the event, the sessions covered how software is actually built now: fast, AI-assisted, dependency-heavy, and spread across more people and systems than any one security team can fully monitor alone. The strongest sessions focused on incentives, workflows, trust boundaries, and the places where attackers keep finding leverage because defenders still leave too much to intent, memory, and good luck.

Here are just a few notes from SnowFROC 2026.

The Human Layer in Secure Defaults

In the keynote from Tanya Janca, founder of She Hacks Purple Consulting, called "Threat Modeling Developer Behavior: The Psychology of Bad Code," she explained that in AppSec, insecure code is rarely just a technical failure. It is usually a human one. Developers work under pressure, chase deadlines, respond to incentives, and fall back on habits, biases, and shortcuts that feel reasonable in the moment. Instead of telling people they are wrong and expecting better outcomes, AppSec teams need to understand why those choices happen in the first place. Psychology helps explain the gap between what teams say they value and what their systems actually reward.

Tanya talked about intervention and prevention over blame. Secure defaults beat secure intent because they remove friction and make the safer path the easier one. That can look like pre-commit hooks, IDE nudges, secure-by-default templates, and frequent reminders placed where decisions actually happen, not buried in a wiki. The same logic applies to training. Annual compliance sessions and lists of what not to do do not change behavior very well. Teaching secure patterns, explaining the why behind them, and reinforcing them in small daily ways is far more likely to stick. The goal is not more nagging. It is better environmental design.

Tanya shared her experiences about AI-assisted coding triggering automation bias, where people trust confident suggestions too quickly. Tight deadlines push present bias, making future breach risk feel abstract next to immediate shipping pressure. Copying code from forums, skipping tests, ignoring warnings, avoiding documentation, or showing off with clever code all follow similar patterns.

She asked us all to build systems that reward maintainable, tested, secure work and measure what actually matters, including time to fix, adoption of secure patterns, and real vulnerability reduction. If teams want secure coding to be real, they have to make it the path of least resistance.

Trust Has Become a Supply Chain Primitive

Chris Lindsey, Field CTO at OX Security, started his talk "Inside the Modern Threat Landscape: Attacker Wins, Defender Moves, and Your Priorities," with a reminder that choosing not to act is still a choice. In today's threat landscape, a small set of attack vectors keeps showing up in outsized breaches, including credential theft, session hijacking, phishing, typosquatting, browser extensions, DNS poisoning, and software that appears to come from trusted sources. The common thread is trust. Attackers do not usually break in by brute force alone, instead they build credibility first through a convincing email or a familiar package name, or a browser extension that looks legitimate on the surface.

Chris asked us to think in terms of what security leaders are asked by boards all the time and often struggle to answer: what did we actually get for this investment? What we need more disciplined framework for evaluating security spending based on risk reduction per dollar. That means asking better questions up front: what threat does this control address, what does it really cost once licensing, implementation, staffing, and maintenance are included, and what measurable reduction in exposure does it create? This is how you get to structured decision-making. When security teams can explain why one control was prioritized over another in terms that leadership understands, the conversation changes from vague reassurance to defensible tradeoffs.

If software and packages are still being pulled in freely, if extensions get broad permissions without scrutiny, and if reviews stop at surface-level validation, the pipeline stays open to abuse. Chris walked through examples that looked benign at first glance but revealed patterns of Trojan behavior, suspicious permissions, deceptive imports, callback infrastructure, and signs of rushed or obfuscated code. Prioritization is key.

He gave us the practical advice of what we could immediately implement: Scan software before use, review open source with stronger technical oversight, pin safe packages, and introduce cooldown periods. We must adopt a posture in which we rotate keys aggressively, sever malicious command-and-control connections urgently, and embrace AI to scale analysis where it adds real value. Attackers are operating in the real world and have no intention of reading your threat model. Your defenses need to be just as practical and reality-based.

npm's Crisis Is Really an Operations Story

In the session from Jenn Gile, founder of OpenSourceMalware.com, called "npm's dark side: Preventing the next Shai-Hulud," she presented the last year of npm account takeovers and package compromises as a lesson in how malware now rides normal engineering behavior. Jenn drew a sharp line between two kinds of software risk: accidental vulnerabilities and intentionally malicious packages. A vulnerability is a flaw that can be exploited if an attacker has a viable path. Malicious software is built from the start to cause harm, often by targeting developers and build environments directly, and it does not always need the same kind of runtime path to do damage. Malicious code does rely, though, on abusing trust. When trust is the vector, the usual instinct to stay on the latest version can become part of the problem.

The heart of the session was account takeover (ATO) and why npm remains such an attractive target. Install scripts still run by default, and provenance is not mandatory. Long-lived publishing tokens remain common. In practice, that means attackers do not always need to break the package ecosystem itself. They can hijack trust that already exists. Jenn walked through a string of compromises from 2025 into 2026, including phishing campaigns, typosquatted domains, spoofed maintainer emails, CI and GitHub Actions token theft, and follow-on attacks that used stolen secrets to widen the blast radius. The throughline across cases like Nx, Qix, Shai-Hulud, TeamPCP, and Axios was not just a technical weakness. It was how easily trusted maintainers, trusted packages, and trusted upgrade habits could be turned against the people relying on them.

Jenn explained that hardware keys help protect the human authentication path, while trusted publishing helps protect the machine path by tying publication to a specific GitHub Actions identity. Session-based authentication can reduce exposure windows, even if it does not eliminate the risk of phishing. However, strong controls only work if teams actually use them, and right now, friction and bias still get in the way.

Jenn's advice was to treat malware prevention as a team sport across development, product security, cloud security, and incident response. Use lockfiles, avoid automatic upgrades, scrutinize lifecycle scripts, harden CI, scan for malware earlier, rotate and scope credentials, monitor for misuse, and build supply chain playbooks that account for how malware behaves differently from ordinary vulnerabilities, especially in the JavaScript and Python ecosystems.

Scale Comes From Systems, Not Heroics

In the final talk of the day, from Mudita Khurana, an Airbnb staff security engineer, called "Scaling AppSec through humans & agents," they presented a model for handling a world where code volume is rising fast, AI tools are now common, and meaningful portions of code are being produced outside the old IDE-centered workflow. She explained her company is seeing more code, more contributors, and far more code generated with AI than even a few years ago. Today nearly all pull request authors are using AI coding tools weekly, a meaningful amount of code is now written by non-engineers outside the IDE, and a large share of total code is AI-generated. Mudita explained you cannot keep up by adding manual review alone. Their response is a layered one: unified tooling to create consistency, LLM agents to extend coverage, and a human network to bring judgment and context where automation still falls short.

A single security CLI acts as the abstraction layer over capabilities like static analysis, software composition analysis, secrets detection, and infrastructure-as-code scanning, with the same experience, exemptions, and metrics no matter where it runs. That lets security checks show up across the developer workflow, from lightweight pre-commit feedback to fuller pull request scans and post-merge coverage.

On top of that, the team is using AI for security review in a more grounded way than generic prompting. Instead of asking a model for a broad security pass, they feed it security requirements as code, along with internal frameworks, auth models, and known anti-patterns. They also measure prompt changes against a dataset built from real historical vulnerabilities, which gives them a baseline for whether the agents are actually improving.

The part of their plan that Mudita was the most excited to share was their security champions program. They do not treat this program as volunteer side work. It is tied to the engineering career ladder, backed by real responsibilities, and supported with a two-way flow of data between security and the orgs doing the work. These champions help write custom rules, triage findings, support risk assessments, and drive adoption because they understand the business context in a way central security teams often cannot. They have created a feedback loop where human insight improves the tools, the tools improve the signal, and prevention gradually moves earlier, into the IDE, into AI prompts, and into the default way code gets written.

Security that lives where decisions happen

One pattern ran through almost every strong session: security works best when it shows up at the point of action. In an IDE. In a pull request. In a package policy. In a browser extension review. In a token issuance flow. In a prompt used by an AI assistant. Teams still lose time when secure guidance lives in a wiki, a yearly training deck, or a control that runs too late to influence the original choice.

That shift sounds simple, but it changes program design. It favors lightweight friction, contextual signals, paved paths, and small reminders over large annual campaigns. It also favors security teams that can collaborate with developer platforms, identity teams, and cloud teams instead of operating as a separate review function.

The new perimeter is made of borrowed trust

Modern software development depends on borrowed trust. Developers trust registries, packages, maintainers, AI suggestions, browser tools, and automation pipelines. Organizations trust tokens, runners, integrations, and service accounts to behave within expected bounds. Attackers know that every one of those relationships can be bent.

That has direct implications for secrets management and non-human identities. A stolen token, an over-scoped credential, or a poisoned dependency can move through trusted systems much faster than traditional controls were built to handle. The answer is tighter provenance, shorter credential lifetimes, stronger attestation, clearer ownership, and continuous review of the trust assumptions hiding inside delivery pipelines.

Maturity now means feedback loops

There was another persistent theme that we need to focus on creating feedback loops. Behavioral nudges need measurement to know how to improve them. Threat prioritization needs cost and impact models to claim success. AI review needs evaluation against real defects to be meaningful. Supply chain response needs intelligence, containment, and recovery steps that teams can actually execute.

Mature AppSec programs increasingly look like systems that learn. They collect signals, improve defaults, refine detections, tighten identity boundaries, and push lessons back into the places where code and infrastructure are created. The organizations that do this well will handle AI-generated code, secrets sprawl, and NHI governance with more control because they have already built the habit of turning incidents and friction into better operating models.

Mile High City Learnings

SnowFROC 2026, which happens at the highest altitude of any OWASP event, felt grounded in the best way. Talks treated security as daily operating design that focused on how people are rewarded, how trust is granted, how credentials spread, and how teams scale judgment without burning out the humans in the loop. Your author was able to give a talk about how we moved from slow waterfall based deployment to a world of DevOps where we have never deployed more, faster. We have a golden opportunity as we adopt AI across our tool chains to rethink authentication in a meaningful way that might just reverberate through all our stacks of non-human identities. That is the feedback loop we can all benefit from.

For teams thinking about identity risk, secrets exposure, and the governance of machine-driven development, SnowFROC offered a useful path forward. Start with defaults. Reduce silent trust. Treat credentials and dependencies as live operational risk. Then build feedback loops that make the next secure decision easier than the last one. That is a practical agenda, and after a snowy spring day in Denver, it also feels achievable.