Picture a team preparing to release a new customer feature. Development is complete, testing looks good, and the business is ready.
Then a security review identifies a problem with how customer data is accessed.
The team now has to revisit decisions made weeks earlier. The release slips, frustration grows, and everyone feels the pressure.
When designing a DevSecOps practice, this is a useful place to start: what needs to happen throughout delivery so that security concerns are addressed while the team can still act on them easily?
At Xpliancy, our consulting perspective starts with the flow of work. Tools support that flow, but people need to understand the decisions, responsibilities and evidence at each stage.
The DEVOPS INSTITUTE’s The DevOps Standard connects delivery capabilities with governance and measurement, and includes continuous security as a core area. It provides a useful foundation for this way of thinking. Explore the standard.
Here is how we recommend translating that thinking into a practical delivery flow.
1. Plan: agree on what “secure enough to release” means
Imagine the feature allows customers to upload documents.
Before development begins, the product owner, developers, operations and security representatives should discuss a few straightforward questions:
- What information will customers upload?
- Who should be able to access it?
- How could someone misuse the feature?
- What evidence will we need before releasing it?
These conversations turn broad security expectations into clear acceptance criteria.
For example: uploaded documents must only be accessible to authorized users, and suspicious files must be handled safely.
The output is a shared understanding of what the team must build and demonstrate.
2. Design: work through the risks before committing to a solution
Next, the team walks through how the feature will work.
Where will documents be stored? How will access be checked? What happens if a file is too large, contains harmful content or belongs to another customer?
A short threat modelling discussion helps the team identify potential misuse and choose appropriate safeguards.
Our recommendation is to keep the discussion proportionate to the change. A small interface update and a new service handling sensitive information need different levels of attention.
The design should leave the team with clear security decisions and named owners for unresolved risks.
3. Code and build: make the safe approach easy to follow
Developers need usable guidance, approved components and quick feedback.
As code enters the delivery pipeline—the automated route from a code change to a deployable release—checks can identify issues such as exposed credentials, vulnerable dependencies and potentially unsafe code.
For our document upload feature, a dependency check might flag a vulnerability in the library used to process files.
That finding should reach the developer with enough context to act: what is affected, why it matters and what needs to change.
A finding becomes useful when somebody can understand it, own it and resolve it.
4. Test: check how the feature behaves
The next step is to test the running application, including how it responds to misuse.
Can one customer retrieve another customer’s document? Can someone bypass file restrictions? Do access controls still work when requests are changed?
Automated tests help make repeatable checks part of everyday delivery. More complex or sensitive changes may also need specialist security testing.
For every significant finding, define an owner, a treatment decision and a way to verify the fix.
Avoid letting security findings become a separate backlog that delivery teams rarely see.
5. Release: make a decision using evidence
Before deployment, the team should be able to explain what has been tested, what remains unresolved and whether the release meets the agreed criteria.
We recommend defining release rules in advance, with controls proportionate to risk.
Routine changes that meet approved conditions can follow an established route. Higher-risk changes need the appropriate review. Where an exception is justified, it should have an authorized decision-maker, documented reasoning, compensating controls and an expiry date.
The delivery pipeline should retain the evidence supporting these decisions.
That makes release approval easier to understand and review.
6. Deploy and operate: watch what happens in the real world
Once the feature is live, the work continues.
The team needs visibility into service health, unusual access patterns and security events. It also needs clear response arrangements and a practical recovery approach.
For the document upload feature, unexpected download activity could warrant investigation even when the application appears healthy.
Development, operations and security should agree who investigates, who coordinates the response and how fixes move safely into production.
A successful deployment is the beginning of operational responsibility.
7. Learn: feed experience into the next change
Suppose an investigation reveals that access controls worked, but the logs did not provide enough information to understand suspicious activity.
That lesson should lead to an improvement in logging requirements, design guidance or automated tests.
This feedback loop is essential. NIST’s Secure Software Development Framework includes responding to vulnerabilities and addressing their underlying causes alongside preparing the organization, protecting software and producing secure releases. Read NIST SP 800-218.
Every resolved issue is an opportunity to improve how the next feature is delivered.
Making the flow work
The practical flow is:
Security contributes throughout. Accountability should be equally clear: developers address code issues, platform teams maintain delivery capabilities, security specialists guide controls and assess risks, and authorized owners make risk acceptance decisions.
For organizations getting started, our recommendation is to choose one service and follow one change through this entire journey.
Look for unclear handoffs, late decisions, repeated manual checks and findings without owners. Improve those points, then expand the approach.
DevSecOps becomes sustainable when teams can answer three questions at every stage:
What needs to happen? Who owns it? What evidence shows it worked?
This article presents Xpliancy’s practical recommendations. The seven-stage flow is an explanatory structure, informed by the referenced guidance; it is not a prescribed sequence quoted from either source.