Topic starter
02/08/2026 11:48 am
TL;DR: Secure SDLC now has to validate intent, not just syntax, because pattern-based SAST misses missing authorization checks and business logic flaws while OWASP data shows broken access control in 100% of tested apps and AI-generated code is secure only 55% of the time. Traditional pipelines reduce risk, but semantic analysis is now the deciding control for catching what code is supposed to do.
NHIMG editorial — based on content published by Gecko Security: Secure SDLC and business logic flaws
By the numbers:
- Only 55% of AI-generated code was secure, leaving nearly half of generated output with known security flaws.
- Post-deployment fixes cost 30 times more to fix than issues caught during design.
Questions worth separating out
Q: How should security teams test for missing authorization checks in Secure SDLC?
A: Security teams should test execution paths, not just code patterns.
Q: Why do business logic flaws survive traditional application security scanning?
A: They survive because they violate intent rather than syntax.
Q: What do teams get wrong about Secure SDLC and AI-generated code?
A: Teams often assume that if generated code looks correct, it is secure enough to merge.
Practitioner guidance
- Add semantic authorization checks to CI/CD testing Run analysis that verifies whether critical execution paths contain the expected authorization logic before release.
- Map trust boundaries during design reviews Document where identity context changes, which endpoints require authorization, and which services can influence privilege.
- Treat AI-generated commits as security-sensitive changes Apply extra review to generated code that handles authentication, authorization, or data access.
What's in the full article
Gecko Security's full article covers the implementation detail this post intentionally leaves for the source:
- Phase-by-phase secure SDLC activities for planning, design, implementation, testing, deployment, operations, and maintenance.
- Tool-by-tool explanation of SAST, DAST, SCA, IAST, and semantic analysis in a development pipeline.
- The article's comparison of what each testing method catches and what it misses in business logic and authorization validation.
- Operational examples of how Gecko applies semantic indexing to chained application logic and access control paths.
👉 Read Gecko Security's analysis of Secure SDLC and business logic flaws →
Business logic flaws in Secure SDLC: are your controls catching intent?
Explore further
02/08/2026 12:58 pm
Broken access control is an identity failure expressed in application code. Security teams often describe this as a software problem because the symptom appears in code review, but the root cause is governance: the application did not enforce who or what was allowed to act. That makes this a shared concern for IAM, appsec, and engineering leadership. If the intended access decision is missing, the defect is not just technical. The practical implication is that authorization logic must be treated as a first-class control surface, not a secondary implementation detail.
A few things that frame the scale:
- 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
- 15% of commit authors have leaked at least one secret in their contribution history, which shows how development workflows repeatedly surface identity and credential exposure risk.
A question worth separating out:
Q: When should organisations use semantic analysis instead of standard SAST?
A: Use semantic analysis when the risk is about policy enforcement, access decisions, or business logic rather than known code patterns. SAST remains useful for syntactic defects, but semantic checks are the better control when you need to confirm that access boundaries exist and are actually enforced in running application logic.
👉 Read our full editorial: Secure SDLC now depends on semantic checks for authorization gaps