KTKalyan Tamarapalliinktamarapalli.hashnode.dev·May 30 · 8 min readMerkle Manifests: Why Build Servers Cannot Be TrustedIntroduction: The Build Server Is Not a Source of Truth Most CI/CD security models assume one thing without stating it directly: If the build server produced the artifact, the artifact must reflect t00
KTKalyan Tamarapalliinktamarapalli.hashnode.dev·May 23 · 6 min readThe Duress Protocol: Designing CI/CD Security for Human CoercionIntroduction: Security Usually Assumes Voluntary Participation Most security systems assume one thing without saying it explicitly: If a human authorizes an action, they intended to authorize it. Th00
KTKalyan Tamarapalliinktamarapalli.hashnode.dev·May 16 · 4 min readThe Neural Risk Engine: Why Not All Deployments Deserve the Same FrictionIntroduction: Static Friction Is a Design Failure Most CI/CD systems treat all approvals equally. Every deployment: looks the same costs the same effort requires the same action This seems fair. 00
KTKalyan Tamarapalliinktamarapalli.hashnode.dev·May 9 · 10 min readThe Physical Sentinel: Designing an Isolated Approval TerminalIntroduction: The Browser Cannot Be Trusted to Display Truth Most modern approval flows assume the machine requesting an action can also be trusted to display what is being approved. That assumption i00
KTKalyan Tamarapalliinktamarapalli.hashnode.dev·May 2 · 10 min readThe Forensic Black Box: Logs That Cannot Be DeletedIntroduction: Prevention Fails. Forensics Must Not. Most security architectures are built around prevention. That instinct is understandable. Teams invest in: access controls secrets management net00