Beyond the Buzzwords: The 5 I’s That Actually Matter in Application Security

I have lost track of how many leadership forums I have sat in, where execs and professionals assert that their coverage is on the way up or new capabilities are solving their security challenges. Coverage and capability seem to have become a corporate mantra. They’re easy to represent with PowerPoint slides featuring a colourful line chart that trends up. 

It may sound compelling, it is anything but. They suggest that somewhere in the machinery of the enterprise, AppSec is quietly ticking along, protecting us from disaster. In reality, the buzzwords don’t live up to the hype, and the benefits are not quite as substantial as they sound. 

Saying “Our coverage is increasing” does not mean you are covering the assets that genuinely matter. You may not even know where your blind spots are. Declaring “our capabilities are strong” is fine, unless you’re missing core capabilities or they’re not being used effectively. Static analysis will not stop an attacker from introducing a malicious component into your repository, nor will it help if developers ignore the results when they get busy.

Rather than continue the security theatre, I would like to propose a more grounded, human-centric framework for approaching application security. It does not rely on jargon or illusion. It relies on something far more powerful: thinking.

I call it the Five I’s of Application Security … Inform, Integrate, Influence, Innovate, and Iterate.

I have developed this model to help organisations navigate modern software development without pretending that Application Security is a ‘solved problem’ just because a dashboard, consultant, or product says so. Instead of reading abstract theory, hypotheticals, or copying big tech, I am going to walk through each of these “I’s” using relevant examples and statistics and real examples drawn from businesses grappling with the realities of securing their applications in today’s world.

If application security is ever going to be more than a line item in a risk register, we need to shift… not left, but in a new direction. One that speaks plainly, thinks critically, and occasionally, just occasionally, laughs at ourselves along the way.

So here is the 5I Model of Application Security:

INFORM … Because Confusion Isn’t a Strategy

Effective Application Security does not begin with a shiny new scanner, a vendor demo, or another compliance checklist. It begins with clarity. What matters? What am I protecting against? What do I have to work with? These questions may seem simple, but getting clarity isn’t. That’s because clarity is diametrically opposed to complexity, and our software organisations are incredibly and increasingly complex. In security, complexity is usually the enemy. Without clarity, the best tools sit idle, people are solving the wrong problems, and spending is misallocated in ways that create a false (and dangerous) sense of security.

In 2024, Australia logged 1,113 notifiable data breaches. This is the highest number on record since mandatory reporting began in 2018. That is a 25% year-on-year increase. Between January and June 2024 alone, the Office of the Australian Information Commissioner (OAIC) received 527 breach notifications, the steepest half-year figure in three and a half years.

Behind each breach is a technical failing, which would have partially stemmed from a communication failure. Consider the NSW Health Department leak: nearly 600 medical staff, including 67 senior doctors, had personal and professional details exposed. This occurred thanks to a simple misconfiguration on a public site. No nation-state hacker. No zero-day exploit. Allowing directory traversal on a public domain. Was it human error? Missing attack surface analysis? Not found in a penetration test? Deployed without a configuration linter? Many controls could have found the bug, but it demonstrated a lack of clarity around the value of these documents and a lack of accountability around protecting them. 

And then there’s iiNet. In August 2025, attackers stole employee credentials and exposed data of around 280,000 customers; emails, addresses, phone numbers, user IDs. A breach that size did not happen because the attackers had infinite resources. It was the compromise of a single employee account.   iiNet is a complex business. It lacked clarity about which staff have access to what systems and how to identify and protect against abuse..

All these organisations operate without having the right information. That’s the real vulnerability. 

Security policies written in dense jargon, training delivered once a year in boring e-learning modules, and alerts dumped on developers without context don’t inform anyone. They’re confusing, get circumvented, alienate folk, and take everyone away from ‘Why’. These are the exact gaps that make adversaries succesful.

Informing properly means being intentional about how you communicate. It means giving developers the why, not just the what. It means translating technical risks into business impact, so a dev understands that failing to sanitise input isn’t a theoretical concept based on a CWE number. It’s the difference between protecting and sharing customer data. Between welcoming or defending from lawsuits. An unblemished brand, or a laughable one. It means asking people what they don’t understand, and taking responsibility for fixing that gap.

And it’s not just about informing others; you need to remain informed yourself. Good threat intelligence and information sharing can help other organisations even with these breaches. A rising tide lifts all ships.

Inform is about more than telling people something. It is about making that action relevant, repeatable, and resonant. That is how you move from policy to practice and become more secure.

Actionable Tips to Inform Effectively:

• Generic messaging does not cut it. Speak directly to your devs’ context, tech stack, and threats they actually face.
• Rule-following isn’t the goal, comprehension and buy-in are. Developers need to understand the reasoning, to care.
• Delivery isn’t the endgame, impact is. Check if the message landed, not just if it was sent.
• If something is unclear, push for clarity. Ownership of clarity is an essential component of security.
• Turn technical risk into business language. Connect vulnerability to lawsuits, brand damage, etc.
• Speak plainly. What sticks is simple, relatable language, not acronyms or CWE references.
• Curiosity is a security asset. Encourage questions and reward them to avoid under-reporting vulnerabilities.

INTEGRATE … Because Dashboards Don’t Fix Pipelines

Security tools do not protect anything in isolation. Left to themselves, they are little more than expensive ornaments, buzzing in the background, generating alerts no one reads, and collecting dust on dashboards. The real power of any tool only emerges when it is woven directly into the places where developers live and breathe. Giving fast feedback and training in the IDE, quickly identifying bugs in source, blocking malicious or vulnerable packages, tests and validation integrated across a DevOps workflow, and reporting what’s really happening in your cloud and application environments.

Australia’s breach landscape makes this painfully clear. According to the OAIC, 69% of breach notifications in 2024 were caused by malicious or criminal attacks. The most common vectors were phishing (34%) and ransomware (24%). While phishing is more aligned to corporate security, many ransomware incidents are successful because of exploitation of application-layer vulnerabilities. These vulnerabilities can often be identified, mitigated, or otherwise prevented through investment in application security products that are then subsequently integrated to be effective.  

Think about it: a developer writes a new feature, a DevOps pipeline builds and ships it, but security sits outside this loop, reviewing systems and changes infrequently and irregularly.. By the time vulnerabilities are reported, adversaries have already tried or been successful with exploiting them. Is this a tooling issue? No. Many companies already use AppSec products expansively yet fail to integrate natively into a DevOps or agile workflow. Without integration, you are left with security gaps, introducing delays, and encouraging finger-pointing instead of building resilience and genuine protection.

The Qantas breach of 2025 drives this home. Records for 5.7 million customers were exposed; names, email addresses, phone numbers, and dates of birth were compromised after attackers compromised a third-party contact centre platform. The real failure was not a lack of tools; Qantas runs one of the more sophisticated cybersecurity functions in Australia and has invested heavily in vendor ecosystems. The failure was in integration, specifically between keeping third-party suppliers in line with Qantas’ internal security requirements.  Qantas’ core systems were accessed after an initial compromise by a contact centre employee. A disconnect across trust boundaries created the opportunity for the adversary to slip through.

In April 2025, Australian superannuation funds were hit by credential stuffing attacks. Over $500,000 was stolen, and personal data for thousands of members was compromised. The culprit? Weak integration across identity management systems. Basic controls like MFA were inconsistently applied across services. When security is not embedded in every layer of user access, attackers find the path of least resistance.

The thing about Integration is that it is not glamorous. It does not wow executives with shiny graphs. To be honest, maintaining the plumbing between systems will never get you a promotion. But what it does do is maintain the expected standard, and that will stop breaches.. It ensures that Application Security is not a bolt-on afterthought but a native part of the development lifecycle, present across every commit, pull request, build, test, deployment, and production operations. 

The lesson is simple: if you aren’t building simple, native integrations for your developers to consume for application security, then you’re responding and firefighting. Proactively integrating into workflows will keep you on pace, and help your developers write secure code at speed..

Actionable Tips to Integrate Security:

• Bake security checks directly into the CI/CD pipeline. Don’t bolt them on later. Secure workflows should run as code ships, not after.
• Use tools that are API-native and integrate directly into IDEs, ticketing systems, and code repos. Meet developers in their flow, not outside it.
• Appoint trusted security advocates within each team, and genuinely listen to their feedback to close tooling and process gaps.
• Create transparent, shared dashboards that give execs, engineers, and security teams a unified view of AppSec posture and progress.
• Consolidate findings from multiple tools and deduplicate aggressively. Help developers prioritise what matters, not drown in noise.
• Don’t spam teams with raw findings. Enrich vulnerabilities with risk context, exploitability insights, and clear remediation paths.
• Push secure-by-default practices into code templates, cloud configs, and dev tooling, so teams start secure, not patch insecure.

INFLUENCE … Because You Can’t Enforce Culture

Culture is not something you can write into a policy manual and expect people to follow. It is also not born from a PDF on the intranet or a training module ticked off once a year. Culture is lived, not legislated. And when it comes to security, the only way it sticks is when it’s visible, meaningful, and woven into the everyday habits of teams.

You can block builds unless they have no critical or high vulnerabilities. You can force automated patching of vulnerable dependencies.. But without establishing a security culture, your engineers will circumvent, maliciously comply, or otherwise meet the bare minimum target.  I’ve seen engineers suppress real findings just to achieve these targets. That behaviour leads to breaches. It is not the same as cultivating a workforce that genuinely cares about security. Mandates build compliance; influence builds resilience.

The data is sobering: in the second half of 2024, 69% of all Australian data breaches came from malicious attacks. These were not harmless IT hiccups. They translated into real-world business impacts; 36% caused unplanned downtime, 30% resulted in data exposure, and 28% triggered direct financial losses (IDM) .

That means customers are locked out of services, shareholders are losing confidence, and frontline teams are scrambling to fix systems they barely understand.

Look again at the Qantas breach of 2025. It was not just about patching servers and tightening controls after 5.7 million customer records were exposed. The real challenge was repairing trust. Customers wanted to know: “Why should I keep flying with you?” Regulators demanded transparency. Investors expected answers. Qantas had to re-engineer how it communicated, presented accountability, and positioned itself as still worthy of trust. That goes beyond enforcement into the territory of influence-led recovery (The Guardian).

Consider the Nine Entertainment breach, which exposed subscriber data for readers of The Age, Sydney Morning Herald, and The Financial Review. Payment details were not stolen, but the fact that names, addresses, and emails were leaked was enough to shake reader confidence. The technical issue was one thing; the bigger battle was public perception. Nine had to demonstrate accountability and influence opinion, convincing subscribers they still valued their privacy and would lift their security game (The Australian).

This is the critical difference: compliance might stop a fine, but influence is what restores reputation. Culture isn’t changed by slapping wrists or threatening penalties. It changes when leaders demonstrate secure behaviour, teams see their peers rewarded for doing the right thing, and stories of failures and successes circulate openly across the business.

Influence is about making security the default mode of operation, not an awkward afterthought. It is about creating an environment where asking, “Is this secure?” is as ordinary as asking, “Does this build?” Once that mindset takes hold, your organisation isn’t just secure by design; it’s resilient by culture.

Actionable Tips to Build Influence:

• Recognise developers who proactively identify and fix issues early. Visibility breeds reinforcement; celebrate the right instincts, not just results.
• Share near-miss stories and lessons learned. Transparency builds trust, and storytelling shapes culture more than policy ever will.
• Make good security practices visible across teams. Spotlight those adopting best practices so others can learn by example, not by enforcement.
• Run opt-in threat modelling sessions and call out contributors. Voluntary engagement beats mandated training when building real buy-in.
• Use real peer stories, such as “Team X caught this before prod”, instead of abstract mandates. Influence scales when people see peers leading the way.
• Craft security messaging in collaboration with teams outside of engineering; marketing, legal, ops etc, so it resonates across the business.
• Have senior leaders walk the talk. When leaders practice, own, and publicly reward security-minded actions, they become part of the organisation’s identity.

INNOVATE … Because Automation Alone Isn’t Enough

We all know that introducing security scanners into pipelines has been the backbone of most AppSec programs. They churn through codebases, spit out vulnerabilities, and feed dashboards that look reassuringly full of red, amber, and green. But let’s be honest: scanning is not innovation. Real innovation in application security is something far deeper. It is the ability to spot the unspoken problems, the gaps vendors aren’t able to profitably solve, and to find novel methods to address them with creativity, curiosity, and courage.

The stakes have never been higher. In 2024, Australia saw 47 million accounts breached. This is a staggering twelvefold increase from the year before. That works out to nearly one compromised account every second. (Surfshark) 

If scale is meant to help us, clearly, it is not working. As businesses digitise and accelerate, the attack surface balloons, and the problems don’t just multiply; they amplify. To keep pace with adversaries, we need to innovate. 

The challenge? You cannot outsource innovation. Ask any creative to churn out books, blogs, or artwork. They’ll be uninspired, shallow, and worthless. So why is buying another shiny tool any different if your workflows, people, and processes remain stale too?. Vendors can solve problems, but only the most common ones.; Only your teams truly understand internal pain, and then further what can create genuine breakthroughs. Innovation flourishes when teams are given breathing space to think, experiment, and build, not just to integrate and remediate.

Some of the most impactful improvements I have seen in Application Security did not come from million-dollar platforms. They came from small, homegrown ideas. A developer writing a quick script on a Friday afternoon that curls externally for known internal domains and raises a JIRA flag if found. A security engineer enriches vulnerability data with other sources so developers don’t just get a red flag; they get context and a one-click code snippet to resolve it. A product team running an impromptu “threat modelling hackathon” that uncovered a complete misunderstanding of how the backend handles a race condition, preventing customer exposures weeks before go-live. 

This is what innovation in AppSec looks like: not complexity for its own sake but elegant, practical solutions to real problems. It permits curiosity and rewards the courage to try something different. Sometimes, those experiments fail. And that is OK. Every failed experiment teaches you more than a tool that sits idle, humming in the background, pretending to protect.

Innovation in AppSec is not just about keeping pace with adversaries; it is about shifting the balance so they have to keep pace with you.

Actionable Tips to Foster Innovation:

• Dedicate time for “innovation sprints” where security and dev teams can test, prototype, and play with new approaches. Space to think creates breakthroughs.
• Showcase homegrown solutions such as scripts, dashboards, micro-tools, so others see what’s possible without waiting for vendor products.
• Run cross-functional hackathons on live issues. When ops, dev, and security solve problems together, creativity scales.
• Build a fail-fast culture where experiments are safe to try. Every failed attempt teaches more than unused tools humming in the background.
• Protect focus time for engineers by carving out no-meeting windows dedicated to security problem-solving.
• Test small, internal prototypes before you buy external tools. Prove value in your context before adding more vendor noise.
• Recognise ingenuity openly. Celebrate curiosity, initiative, and experiments, even those that don’t reach production.

ITERATE … Because Threats Don’t Stop Evolving

Security is more than a box you tick. It is a muscle you train. And like any muscle, if you stop working it, it weakens. Too often, organisations treat security as a project with an end date. They roll out a new policy, deploy a tool, deliver a round of training, and then move on. But attackers don’t move on. They adapt. They study your patterns, watch your rhythms, and wait for you to feel comfortable. That’s when they strike.

In 2024, Australia recorded a record 1,113 data breaches. That is not just a reflection of increased digital exposure; it is a sign that our defences are stagnating. The tactics are getting smarter, the payloads nastier, and the patience of threat actors longer. Meanwhile, many businesses still operate on quarterly scan schedules and annual policy reviews, as if the world isn’t shifting. When threat actors iterate daily, you can’t afford to adjust annually.

The truth is, every part of your AppSec function … from threat modelling to incident response, should evolve continuously. But that kind of iteration doesn’t come from dashboards or policy decks. It comes from mindset. Good Application Security starts with the right mindset. It comes from treating security like a living system that has to learn, adapt, and improve over time. That means every near-miss is a lesson. Every detection delay is a chance to tighten feedback loops. Every feature release is an opportunity to revisit assumptions. The best teams I have worked with are not the ones that get it right the first time; they are the ones who treat every mistake, every friction point, every false positive as a gift.

Consider the 2025 breach at a major Australian superannuation provider. Credentials were compromised in a simple, automated attack, but the real issue wasn’t the exploit; it was the response. Weeks passed before controls were tightened across environments, despite the obvious attack vector. The reason? Post-incident reviews were siloed, playbooks were stale, and the organisation had no mechanism to learn at speed. It was not a failure of technology. It was a failure to iterate.

Iteration is not a retrospective exercise. It is not something you do after the damage is done. It is a continuous loop of reflection and refinement built into the daily rhythm of your teams. The highest-performing security cultures I have seen have rituals for this. Rituals whereby they go beyond asking “What happened?” to “What should change?” They revisit threat models when the architecture shifts. They update runbooks when alerts go wrong. They treat feedback not as noise, but as a signal for improvement.

Security that does not iterate is security that atrophies. It slowly drifts from relevance until one day, it breaks. But when iteration becomes cultural and is embedded into your sprint cycles, planning meetings, and release reviews … it becomes your edge. You don’t just respond to change; you anticipate it. You don’t just patch; you evolve.

Because the goal isn’t to build a perfect AppSec program. The goal is to build one that is never finished.

Actionable Tips to Iterate Effectively:

• Refresh playbooks on a consistent cadence so runbooks, governance steps, and comms stay alive and relevant.
• Run post-iteration retrospectives that capture lessons across technology, people, and process in equal depth.
• Revisit threat models with major features or architecture shift to keep assumptions aligned with reality.
• Share learnings broadly across Sec, Dev, Ops, and Legal, and build rituals that make knowledge transfer routine.
• Automate feedback loops so every alert and test directly informs and strengthens the next iteration.
• Track improvements not only by fixes delivered but also by readiness, response speed, and operational resilience.
• Reward adaptability by recognising and celebrating teams who pivot quickly when new opportunities, threats or risks emerge.

Conclusion: The Future of AppSec Isn’t a Dashboard. It is a Discipline

Application security today demands more than tools, reports, and compliance checks. It requires clarity, creativity, cohesion, empathy, and adaptability. 

That’s what the 5 I’s: Inform, Innovate, Integrate, Influence, and Iterate, are about. 

They are not a silver bullet or a neat checklist to work through once a year. They are a mindset shift.

This framework is designed to move organisations beyond the illusion of safety provided by surface-level coverage and cosmetic capability. It refocuses our attention on the human, cultural, and operational elements of security that truly determine resilience.

Because in an environment where software is constantly changing, cloud infrastructure is ephemeral, and adversaries are faster than ever, we don’t just need to react. We need to adapt intelligently and continuously.

Security that works isn’t perfect. It’s practised. It’s responsive. And above all, it’s real.

Next Steps: From Insight to Action

Assess Your Posture Against the 5 I’s
Hold an honest internal retrospective. How well does your organisation inform, innovate, integrate, influence, and iterate across your AppSec function? Where are the gaps?

Choose One “I” to Focus on Per Quarter
Don’t try to boil the ocean. Pick one area and build momentum. Inform your teams better this quarter. Integrate your tools more deeply next.

Engage Developers and Security Staff in Co-Design
Ask them what’s working, what’s broken, and what’s slowing them down. Co-design solutions rather than enforcing them.

Tie Security to Business Value
Whether it’s reduced downtime, avoided breaches, or improved velocity—measure what matters. And communicate it.

Embed Security as a Culture, Not a Constraint
Turn security from the “department of no” into the “team of how.” Recognise good behaviour. Share stories. Build influence, not just enforcement.

Call in Help When Needed
If you are not sure how to start or need an external lens to guide your transformation, bring in a partner (like Galah Cyber) who understands Application Security deeply, and practically.