Category
Building security into software architecture, delivery pipelines, embedded products and the decision to ship.
Most security defects are decisions that were never examined: a trust boundary nobody drew, an authorisation rule that lived only in one developer’s head, a dependency adopted on a deadline, a device that shipped without a route to update it. This category covers secure architecture and threat modelling, security requirements and secure-by-design practice, the security lifecycle inside ordinary delivery, application, API and integration security, secure code review and remediation, software supply-chain control, embedded and firmware engineering, security protocol work, and the evidence a release decision should rest on. It treats security as an engineering property of the product rather than an audit performed on it afterwards.
Most APIs authenticate well and authorise badly. The defects that matter are object-level and function-level access rules scattered across handlers, where no single reviewer can see the whole rule.
Most threat models are produced once, filed, and never consulted again. A model earns its place when every ranked attack path is attached to an architectural decision someone has to make.
Adding every available scanner to continuous integration produces a slow pipeline and a culture of overrides. Choose gates by what they can decide reliably, and move the rest out of the blocking path.
A software bill of materials tells you what you ship. Controlling supply-chain risk needs three further things: provenance for the build, a policy for adoption, and a rehearsed route to replace a component quickly.
Almost every custom security protocol should have been a profile of an existing one. The few that are justified share a specific set of constraints - and a review process that assumes the first design is wrong.
"The scans are green" is not a security release decision. A defensible one states what was tested, what is known to be wrong, who accepted it, and what would change the answer.
Teams treat secure boot as a firmware feature and discover years later that the hard part was never verification. It was deciding who holds the signing key, how it rotates, and what happens when it is lost.
A review that delivers a ranked findings report usually changes nothing. A review that delivers a patch, a test that fails before it and a pattern the team can apply changes the codebase.
A device in the field may be unreachable for months and in service for a decade. That constraint should change the architecture, not just the update policy.
"The system shall be secure against unauthorised access" cannot be implemented, reviewed or verified. Security requirements become useful when each one names an actor, a condition and an observable result.
Bring one agent workflow and the decision in front of you. Gaurav Tiwari replies personally within 1 working day.