Today I was asked a simple question:

“Where does security start when it comes to software development?”

My answer is still the same: security starts with the developer.

Not with the annual checkbox. Not with the quarterly training video. Not with the login screen that proves someone completed a security class. Those things may be required in the enterprise, and they can be useful, but they are not where real software security starts.

Real security starts when a developer understands what secure code means.

Secure code is not just code that compiles. It is code that handles input correctly, protects data, uses authentication and authorization properly, manages errors without leaking sensitive information, avoids unsafe memory behavior, uses approved libraries, and follows architecture patterns the enterprise already trusts.

Secure software development is not one activity. It is a system.

It includes secure requirements, threat modeling, framework selection, code review, automated testing, dependency scanning, software composition analysis, CI/CD controls, and production observability. NIST’s Secure Software Development Framework supports this view by recommending secure development practices across the software development life cycle, not after the software is already built.

Security Starts Before the Pull Request

A lot of enterprises require developers to take security training every few months. That is fine, but training alone is not enough.

The better question is this:

Can the developer recognize insecure code before it becomes production code?

That is where code review matters. Reviewing code is not just about formatting, naming, or whether the code follows the team’s style guide. Good review asks deeper questions:

• Is this input trusted?
• Is this framework being used correctly?
• Is this custom implementation replacing something the platform already solves?
• Does this change weaken authorization?
• Does this expose data?
• Does this introduce a dependency that should not be here?
• Does this generated code contain a vulnerability that looks harmless at first glance?

Security starts when developers are trained to think this way and when the engineering process reinforces that behavior every day.

Frameworks Are Security Controls

One of the biggest mistakes teams make is treating frameworks as convenience libraries instead of security controls.

A mature framework is not only there to save keystrokes. It gives the team hardened defaults, proven patterns, predictable configuration, tested integrations, and community-reviewed behavior. In enterprise software, using a proven framework correctly is often more secure than building custom code to solve a problem the ecosystem already solved.

This is especially true in Java and Spring-based enterprise systems. Authentication, authorization, input handling, validation, serialization, database access, observability, and configuration should not be invented from scratch by every team.

Custom code is sometimes necessary. Custom security infrastructure should be treated with extreme caution.

A recent VMware Tanzu Spring announcement is a good example of this principle in practice. Tanzu Spring announced SLSA Level 3 compliant Java dependencies for Spring Boot 2.7.x, 3.x, and 4.x. More specifically, this is not a blanket claim that every Spring Boot application is automatically SLSA Level 3 compliant. The announcement is about clean room builds and provenance for the Spring Boot Java dependency tree available through the Spring Enterprise Repository.

That distinction matters.

The value is not just that developers are using Spring Boot. The value is that the enterprise can consume a verified dependency supply chain from a trusted source. According to the announcement, Tanzu Spring customers now have access to secure, clean room builds of the Java dependency tree for Spring Boot 2.7.x, 3.x, and 4.x, including provenance for more than 5,000 verified Java library dependencies from a single trusted source.

That is a security control.

Framework security is no longer only about the code the framework gives you. It is also about the supply chain behind the framework. Modern enterprise applications depend on large transitive dependency trees. If those dependencies come from unknown, unaudited, or unverifiable build paths, the application inherits that risk.

Mature enterprise frameworks and trusted artifact sources reduce the amount of custom security-critical code teams write, and they improve confidence in the dependencies teams consume.

That does not remove the need for code review, dependency scanning, SBOMs, SAST, SCA, or runtime controls. But it does prove the larger point: security starts earlier than the scan. It starts with the engineering choices developers and architects make before the code ever reaches production.

The Buffer Overflow Lesson Still Matters

The classic example is still the buffer overflow.

A buffer overflow is not just an old C or C++ problem people mention in security classes. It is a reminder that vulnerabilities often start as ordinary engineering mistakes. A boundary was not checked. Input was trusted. A library was used incorrectly. A reviewer missed it. A generated code change was accepted without enough scrutiny.

MITRE’s CWE Top 25 continues to include serious software weakness classes such as cross-site scripting, SQL injection, missing authorization, out-of-bounds write, path traversal, use-after-free, out-of-bounds read, command injection, code injection, classic buffer overflow, deserialization of untrusted data, improper input validation, and improper access control.

These are not abstract academic concerns. They are common and dangerous weakness classes that can lead to system compromise, data exposure, privilege escalation, or service disruption.

This is why security cannot belong only to the security team.

Security has to be part of how code is written, reviewed, tested, packaged, and shipped.

Where Snyk-Like Tools Fit

Tools such as Snyk, Dependabot, OpenSSF Scorecard, SBOM tooling, SAST, SCA, container scanners, and infrastructure-as-code scanners play an important role.

But they do not all solve the same problem.

Software composition analysis helps identify vulnerable dependencies. It tells you whether the packages, frameworks, containers, and infrastructure components you are using have known vulnerabilities.

That matters because modern software is assembled as much as it is written. Most enterprise applications depend on open-source packages, transitive dependencies, containers, build tools, plugins, and infrastructure configuration. Risk can enter through code your team wrote, but it can also enter through code your team imported.

That is different from code review.

Dependency scanning asks:

Are we using something vulnerable?

Code review asks:

Did we build something vulnerable?

You need both.

An SBOM can tell you what is inside your software. SCA can tell you whether known components have known CVEs. Code review, static analysis, tests, and architectural review help determine whether your own code introduces risk.

What AI Should Change

This is where AI-assisted code review becomes important.

If AI is used only to generate more code faster, we are going to create security debt faster.

But if AI is used to review code, challenge assumptions, identify risky patterns, check framework usage, explain potential vulnerabilities, and enforce secure engineering standards, then it can improve the software delivery process.

That does not mean AI will eliminate vulnerabilities.

It should mean fewer obvious vulnerabilities make it through review.

The future should not be a world where tools keep finding the same preventable issues after the fact. The goal should be to catch more issues before they become releases, incidents, CVEs, emergency patches, or customer-facing failures.

AI-assisted review should help reduce repeated classes of defects:

• Poor input validation
• Unsafe deserialization
• Broken authorization
• Improper error handling
• Insecure dependency usage
• Custom security code replacing mature framework features
• Weak tests around security-sensitive behavior
• Risky generated code accepted without review
• Configuration mistakes
• Architecture decisions that expand the attack surface

This only works if AI is part of a governed engineering system. AI review must be tied to rules, standards, architecture, trusted frameworks, CI gates, and human accountability.

The goal is not to replace security tools. The goal is to move more security knowledge into the daily development workflow.

Better Software Should Mean Fewer Preventable Vulnerabilities

Here is the part I think enterprises should start expecting.

If teams are using better code review, stronger framework defaults, secure dependency sources, SCA, SBOMs, SAST, and AI-assisted review, then the number of preventable vulnerabilities should go down.

Not all vulnerabilities will disappear. That would be an unrealistic claim.

But many classes of avoidable issues should become less common:

• The obvious injection flaw.
• The missing authorization check.
• The unsafe generated code.
• The custom security implementation that should have used the framework.
• The vulnerable dependency pulled from an untrusted source.
• The transitive dependency nobody knew existed.
• The risky configuration that should have been caught before merge.
• The insecure pattern that keeps showing up across services.

This is where AI-assisted review can add real value. It can help reviewers focus. It can explain why a pattern is risky. It can compare code against secure coding rules. It can help developers learn while they work. It can make security feedback faster, more consistent, and closer to the code.

But the enterprise still needs the full system: secure frameworks, trusted artifact repositories, dependency scanning, SBOMs, automated tests, CI/CD gates, human review, observability, and accountability.

AI should make the system better.

It should not become another excuse to skip the system.

Security Is an Engineering Discipline

Security does not start when the security team scans the finished product. It starts earlier, when engineering makes the right decision before the code exists.

It starts with developers who know how to write secure code and reviewers who know what insecure code looks like. It starts with teams that choose proven frameworks instead of inventing security-critical plumbing, architects who reduce risk through design, and enterprises that consume dependencies from trusted, auditable sources. And it starts when dependency scanning, SBOMs, SAST, SCA, AI-assisted review, and human review work together instead of in silos.

The enterprise does not need more checkbox security.

It needs secure engineering discipline.

And that starts with the developer.