Alefita's Secure SDLC: The 7-Phase Lifecycle
Complete Secure SDLC methodology: 7-phase lifecycle, Security by Design, Green-Mile analysis, Red-to-Blue Team loop, analytical patterns, and AI security framework.
Alefita's Secure SDLC Protocol
Source:
SDLC_PROTOCOL_REPORT.md(2026-07-22),playbook_bairesdev_appsec_alefita.mdCross-references: co-fita-green-mile, co-fita-red-team-blue-team, co-fita-harness, clickfix-attack-chain, kaggle-agent-security
The 7-Phase Lifecycle
The Secure SDLC is not a checklist. It is a system of feedback loops where each phase feeds forward into the next and backward into previous phases when incidents occur. This is the methodology Alefita practiced at RD Saude, refined through CAMDOM, and formalized in the BairesDev AppSec playbook.
graph LR
P1[1. Planning] --> P2[2. Design]
P2 --> P3[3. Development]
P3 --> P4[4. Build & Release]
P4 --> P5[5. Runtime Testing]
P5 --> P6[6. Operations]
P6 --> P7[7. Feedback & Control]
P7 -.->|"back-feed"| P1
P7 -.->|"back-feed"| P2
P6 -.->|"incident back-feed"| P2
Phase 1: Planning
Classify data, business actions, regulatory context, threat surface and security requirements. Identify what must never happen and what evidence will be required.
The Six Questions
Before implementation begins, six questions must be answered:
- What data and business actions are at stake?
- Who is allowed to perform each action?
- Which component owns the authorization decision?
- What happens when the client is modified or bypassed?
- Which trust boundaries exist between mobile, gateway, proxy, and core services?
- What evidence will prove that the intended control is active?
Question 4 is the most important. It is the question that produced the co-fita-green-mile finding.
Practice Evidence
RD Saude: Before any API or mobile feature reached development, the security engineering function classified data types (PII, payment cards, auth tokens), business actions (account takeover, billing manipulation), and regulatory exposure (LGPD, PCI DSS). This was structured conversation between security, product, and engineering leads -- not a form-filling exercise.
LuizaLabs: The SuperApp feature inheritance demonstrates planning as a decision point. Alefita diagnosed architectural fragility that would compound security and maintenance costs. Shipping now and accumulating debt vs. investing in the foundation -- this is a planning-phase security decision.
CAMDOM: Planning required mapping an entirely new threat surface: physical proximity, BLE radio range, cross-platform protocol differences, offline constraints, and the social safety problem. Security requirements -- zero data collection, no cloud dependency, hardware-level protection -- were defined before a single line of code. See camdom-architecture.
Phase 2: Design
Map trust boundaries, identities, service ownership, authorization decisions, secrets, failure modes and abuse cases. Review API contracts and architecture before implementation.
Security by Design
The core principle: make the safe architecture the default architecture. When the gateway enforces authentication, authorization, input validation, and rate limiting by default, individual teams do not need to rediscover the same security decisions for every new endpoint.
API Governance as Control Plane
The RD API Governance Playbook is the architectural expression of Security by Design:
| Mechanism | What It Encodes |
|---|---|
| Separation of concerns | Gateway handles auth/authz/validation; services handle business logic |
| OpenAPI contracts | Machine-readable interface definition (control surface, not documentation) |
| HATEOAS | Clients discover actions through links, not leaked implementation details |
| Consultative onboarding | Security function as enabler, not gatekeeper |
| Gateway policy | Security decisions encoded once, enforced everywhere |
The scaling insight: AppSec scales when teams do not need to rediscover the same security decisions for every API. The gateway policy, the contract standard, the onboarding process -- these are infrastructure that encode security decisions once and enforce them everywhere.
CAMDOM Design Outputs
The design phase produced:
- Leader election protocol for BLE role assignment (highest-value-wins)
- Platform-specific advertising value ranges for cross-platform disambiguation
- Session-based connection handshake with UUID v4 identifiers
- Mutual disconnection protocol requiring all parties to agree
- RSSI proximity detection using rolling windows
- Privacy by design: zero analytics, zero telemetry, zero network calls beyond BLE
Phase 3: Development
Use secure coding guidance, peer review, SAST, SCA, secret scanning, tests and small changes. Generated code must receive the same or stronger verification as human-written code.
AI-Generated Code as Untrusted Input
The playbook's position is unambiguous: treat model output as untrusted input. Require tests, linting, SAST, SCA, secret scanning, dependency validation, review, and CI gates.
Why: AI-generated code may contain insecure patterns absorbed from training data, hallucinate non-existent or vulnerable dependencies, leak credentials embedded in context, implement authentication incorrectly while appearing syntactically correct, or use deprecated/vulnerable API patterns.
The pipeline: AI-generated code enters the same pipeline as human code. Same tests. Same SAST. Same SCA. Same secret scanning. Same review. Same CI gates. Plus additional controls for data boundaries and agent permissions.
Real-World Development Under Pressure
The CAMDOM codebase (429 commits, 8,967 lines) reveals what shipping under real constraints looks like:
| Strength | Weakness |
|---|---|
| TypeScript strict mode enabled | 1,877-line god object |
| Clean naming conventions | Zero test coverage |
| Elegant generator-based animation engine | 115 lines of commented-out code |
| 429 commits of iteration | 13+ magic numbers |
This is honest. The playbook's development phase standards exist precisely because these pressures produce predictable failure modes. The code quality score of 3.6/10 is not a failure -- it is a documented trade-off under Cannes Lions submission timeline pressure.
Phase 4: Build and Release
Use reproducible artifacts, dependency validation, policy gates, environment controls and explicit exception handling.
Risk-Based Blocking
The playbook distinguishes between blocking criteria and scanner severity. A finding blocks release based on:
| Factor | Question |
|---|---|
| Exploitability | How easy is it to exploit? |
| Exposure | Is the component internet-facing? |
| Asset sensitivity | What data is at risk? |
| Business impact | What is the consequence? |
| Confidence | How certain is the finding? |
| Compensating controls | Are there mitigations in place? |
| Time to remediate | How long until a fix is available? |
Scanner severity alone is insufficient.
Exception Handling
When a finding does not block release, it requires an expiring exception with an owner and a retest plan. Exceptions are not baselines -- they are temporary deviations that must be resolved or escalated.
CAMDOM example: The RSSI proximity feature is disabled (115 lines of commented-out code) rather than removed. This is a documented exception: the feature was not reliable enough for production but represents a capability worth preserving. The code exists as an explicit exception, not accidental deletion.
Phase 5: Runtime Testing
Combine DAST, IAST, API authorization tests, manual testing and threat-informed regression. Static and dynamic findings answer different questions; neither is sufficient alone.
The Method Comparison
| Method | Strength | Weakness |
|---|---|---|
| SAST | Insecure patterns, data-flow problems, early | Weak when exploitability depends on runtime config |
| DAST | Observable runtime behavior, config issues, attack paths | Requires realistic environments, careful triage |
| IAST | Runtime behavior with code context | Depends on instrumentation and coverage |
| SCA | Dependency inventory, vulnerability and license tracking | Must pair with lockfile integrity and SBOM |
| Manual/Adversarial | Business-logic abuse, authorization chains, attacker creativity | Cannot be automated; requires reasoning |
The Critical Insight
Automated tools increase coverage; they do not eliminate reasoning. Human testing is needed for:
- What happens when a mobile client is instrumented with Frida
- When authorization is tested across multiple object types and roles
- When an attacker chains two individually low-severity findings into a high-impact exploit
This is exactly what happened in co-fita-green-mile: the IDOR vulnerability was exploitable not because of a single bug, but because of a chain of architectural gaps that no single scanner could model.
Phase 6: Operations
Monitor relevant abuse signals, keep vulnerability intake connected to ownership, patch within risk-based SLAs, rehearse rollback and feed incidents back into design and tooling.
ClickFix: Operations in Real Time
The clickfix-incident-response on 2026-06-25 demonstrated the operations phase under live attack:
| Metric | This Incident | Industry Average |
|---|---|---|
| First alert to AI response | 1 second | -- |
| Alert to malicious process identified | 16 seconds | -- |
| Alert to LaunchAgent persistence found | 101 seconds | -- |
| Alert to system declared clean | 160 seconds | 70 minutes (containment) |
| Full forensic chain revealed | ~24 minutes | 207 minutes (detection) |
The 160-second containment was possible because the operational phase was not improvised. The response followed the structured loop: identify persistence, understand the respawn mechanism (KeepAlive: true), unload the LaunchAgent before killing processes, verify artifacts, document the full chain.
The back-feed: The operations phase feeds into design. The ClickFix attack revealed that expired domains in trusted repositories (supply chain risk) are a permanent threat surface that must be modeled in the planning phase.
Phase 7: Feedback and Control Encoding
Turn the lesson into a reusable control, standard or pipeline check. Measure whether the control reduces meaningful risk without destroying delivery flow.
The Seven Requirements
A finding is not complete when a ticket exists. It needs:
- Clear affected asset and owner
- Reproducible evidence
- Severity tied to exposure and business impact
- Root-cause diagnosis
- Remediation or compensating control
- Retest and regression evidence
- A durable lesson for standards, templates, or automation
What Separates Security Engineers from Pentesters
The pentester delivers a finding. The security engineer encodes the finding into a control that prevents the entire class of vulnerability from recurring.
This seventh phase is the through-line across all of Alefita's work:
| Project | Control Encoded |
|---|---|
| Green-Mile | 5-layer fix model (client, gateway, service, data, process) |
| CAMDOM | BLE proximity protocol as a reusable pattern for consent |
| ClickFix | Forensic documentation + longitudinal monitoring protocol |
| Co-Fita | co-fita-governance -- governance proposals as encoded operational lessons |
| Wikifita | wikifita -- OKF as encoded knowledge management standards |
Vulnerability Management as System
The playbook defines vulnerability management not as "find and fix" but as a complete lifecycle:
graph LR
INT[Intake<br/>Triage + Ownership] --> DIAG[Diagnosis<br/>Root Cause]
DIAG --> REM[Remediation<br/>Fix at Correct Layer]
REM --> VER[Verification<br/>Retest + Regression]
VER --> ENC[Encoding<br/>Durable Control]
ENC --> MON[Monitoring<br/>Track Recurrence]
MON -.->|"feedback"| INT
| Stage | What Happens |
|---|---|
| Intake | Findings triaged with clear asset identification, ownership assignment, severity tied to business context |
| Diagnosis | Root cause identified. An IDOR is not just a bad endpoint -- it may indicate missing ownership semantics, weak gateway policy, absent API standards |
| Remediation | Fix applied at the correct layer (see co-fita-green-mile). Compensating controls documented when immediate remediation is not possible |
| Verification | Retest with regression evidence. Finding not closed until proof exists that fix works |
| Encoding | Lesson becomes a standard, template, pipeline check, or design pattern |
The Five Analytical Patterns
The playbook identifies five recurring decision-making patterns that appear across every project in Alefita's career.
Pattern 1: Move from Symptom to System
Ask whether an observed failure is local or structural.
| Case | Symptom | System Diagnosis |
|---|---|---|
| Green-Mile | IDOR in address proxy | Missing ownership semantics, weak gateway policy, absent API standards |
| ClickFix | Compromised clipboard | Supply chain trust model treats repo links as permanent |
| CAMDOM | Privacy breach risk | Apps depend on cloud services, software locks, single-device protections |
| LuizaLabs | "Near-finished" fragile feature | Debt decision, not shipping decision |
Pattern 2: Preserve the Future System
Accept schedule cost to avoid shipping architecture that would multiply future costs.
| Case | Decision | Rationale |
|---|---|---|
| LuizaLabs SuperApp | Substantial refactor over shipping | Total cost of ownership and risk compounding |
| CAMDOM | Full rewrite in final 15 days | Cleaner Expo Modules abstraction; original architecture would accumulate workarounds |
| RD API Governance | OpenAPI + HATEOAS + centralized gateway | Per-team security decisions reduced from O(n) to O(1) |
Pattern 3: Make Trade-offs Explicit
Separate hard constraints from preferences. Distinguish temporary exceptions from new baselines. Ask who owns the risk.
Release blocking formulation: "I use risk, not scanner severity alone: exploitability, exposure, asset sensitivity, business impact, confidence, compensating controls and time to remediate. I block when residual risk exceeds the agreed threshold; otherwise I document an expiring exception with an owner and retest plan."
Pattern 4: Learn Through Instrumentation
Conclusions are based on evidence, not intuition alone.
| Project | Evidence Sources |
|---|---|
| ClickFix | Safari History.db, LaunchAgent plists, process listings, blockchain transactions |
| CAMDOM | RSSI rolling windows, explicit state machine transitions, deterministic election algorithms |
| RD Saude | Burp Suite, Frida hooks, JADX inspection, postmortem analysis |
| Kaggle | 7 attack primitives identified through structured experimentation |
Pattern 5: Turn Knowledge into Infrastructure
Create playbooks, templates, governance rules, pipeline controls so expertise becomes organizational capability.
| Project | Infrastructure Created |
|---|---|
| RD API Governance | Living document encoding security decisions as architectural standards |
| CAMDOM | BLE protocol specification, leader election algorithm, session handshake -- reusable patterns |
| Co-Fita | co-fita-governance -- Centralismo Democratico turns failures into governance proposals |
| Wikifita | OKF standard, structured memory, constitutional directives |
AI Security Framework
Agentic Workflow Controls
For agents that can read repositories, call tools, or write code, the playbook defines seven control categories:
| Control | Purpose | Co-Fita Implementation |
|---|---|---|
| Least-privilege identities | Agent operates with minimum necessary permissions | Worker agents scoped to roles; cannot self-promote |
| Tool allowlists | Agent can only invoke approved tools | MCP server capabilities governed by proposal categories |
| Sandboxing and data boundaries | Agent cannot access data outside its scope | Operations scoped to project directories |
| Explicit approval points | Human reviews before high-risk actions | Chancela system |
| Output validation | Agent output verified before consumption | Elo tournament debate |
| Reproducible traces | Every action logged and auditable | Append-only JSONL logs |
| Kill switches and rollback | Ability to halt and revert | Veto mechanism |
Connection to Kaggle Competition
The kaggle-agent-security competition (OpenAI, Google, IEEE) validates this framework empirically. The four measured predicates map directly to playbook controls:
| Predicate | Severity | Playbook Control |
|---|---|---|
| EXFILTRATION | 5 | Sandboxing + data boundaries + tool allowlists |
| UNTRUSTED_TO_ACTION | 5/4 | Explicit approval points + least-privilege identities |
| DESTRUCTIVE_WRITE | 4 | Sandboxing + output validation |
| CONFUSED_DEPUTY | 3 | Explicit approval points (human-in-the-loop) |
The 7 Attack Primitives
From attack-primitives, seven behavioral patterns in language models that can be exploited:
- Identity Steering -- Models accept any identity the prefill assigns
- Decision-Collapsing -- Models silently re-prioritize multi-component instructions
- Urgency Vectors -- Urgency framing increases probability of destructive actions
- CoT Post-Hoc Rationalization -- Chain-of-thought rationalizes after the forward pass decides
- ROP Gadget Chains -- Models reuse existing reasoning features for emergent behaviors
- Linguistic Heterogeneity -- Safety guardrails are trained predominantly on English
- Steganography in CoT -- Models encode hidden information in reasoning traces
Each primitive has a corresponding defensive control in the playbook's framework.
Career Synthesis
The SDLC protocol is not theoretical. It is demonstrated practice across five years of progressive capability accumulation:
| Period | Role | Capability Layer |
|---|---|---|
| 2019-2022 | Mobile Developer, Tech Lead | Foundation: build, debug, ship production software |
| 2022-2024 | Tech Lead Cyber Security (RD Saude) | Security: pentesting, Security by Design, API governance |
| 2024 | CAMDOM (Solo Developer) | Product security: BLE mesh, cross-platform, privacy by design |
| 2025-present | R&D Specialist (LuizaLabs) | AI security: Gen AI, ML, React Native, engineering judgment |
| 2026 | Research (Kaggle, ClickFix, Co-Fita) | AI governance: agent security, APT forensics, governance systems |
Each role added capability without abandoning previous capability. The differentiator is the ability to move between abstraction levels: API contract, mobile binary, CI pipeline, cloud boundary, organizational ownership, and business consequence.
"I work across the whole security lifecycle: I find what can be abused, understand why the architecture allowed it, fix it at the right layer, and convert the lesson into a control that teams can repeat."
This document is alive. It evolves as the research evolves. Challenge it. Improve it. That is the protocol.