This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.
The pipeline you have, plus one gate
DevSecOps here means the build you already run grows one security check you can explain. A secret in a repository you own is removed and rotated. A dependency you do not understand is not added in the same hour. The pipeline planner drafts stages. The secrets scanner looks at text you are allowed to scan. You do not point it at someone else's code.
A failed check stops the build or it is not a check. A check that always passes is a log line. Start with one: secrets, or a config audit the review guide already describes.
The cloud desk's infrastructure guide is the companion for how the template is written. This page is the decision to fail the build.
Rotating a leaked key is the leaked-credentials and API-key guides if the secret was real. Finding the pattern is not the rotation.
A lab repo with a fake secret and a failing build
In a lab repository, commit a file that contains the text prompt-for-this and a shape your scanner treats as a secret, not a real key. Run the scanner. The build fails. Remove the file. The build passes. That pair is the proof.
If a real secret was already in the history, rotation is mandatory even after you delete the file. History keeps it. The ticket says rotated, and the old value is not printed.
Add the scanner as a required check on the default branch only after the lab pair worked. A required check you cannot bypass with a named exception will block you. Write the exception path before you require it.
Do not add five scanners because the planner offered five stages.
A change you can finish
Production is one required check on one repository, after the lab fail and the lab pass.
Rollback is making the check non-blocking, which you practised, while you fix a false positive. You do not delete the scanner config without a note.
- Pick one repository you own.
- Run the scanner on a fake secret in the lab.
- See the build fail, then pass when the fake is gone.
- Rotate any real secret the scanner found. Do not print it.
- Write how a false positive is excepted.
- Require the check on the default branch.
- Leave the next scanner for a later window.
Mistakes that outlive the command
DevSecOps fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.
- Scanning repositories you do not own.
- A real key committed to prove the scanner works.
- Deleting a secret from the latest file and not rotating it.
- A check that cannot fail.
- Five new gates in one afternoon.
- An exception path that is everyone, always.
- Printing the secret in the build log.
- Pointing the pipeline at production credentials to test it.
Decisions to write down before the window
One decision for DevSecOps: The repository is yours. The lab secret is fake. The build failed and then passed. A real finding is rotated, not only deleted. The check is required only after that pair. Exceptions are named and rare. Logs do not print secrets. The config review guide owns Dockerfile, Kubernetes, Terraform, and workflow audits. Rollback is un-requiring the check. And one gate in this window.
The hour you stop
Write the hostname or the system name, the owner, and the clock time before you change anything for DevSecOps. If the system is serving people and you do not have a spare, this hour is a plan, not a change. A plan you can read tomorrow is a success. A change you cannot undo is not.
Use a lab or a copy. The log line you test with is one you created, or one you are already allowed to hold. You do not point a tool at a network, a mailbox, or an account you do not administer. The tools on this site run in the browser. They do not log in, and they do not scan.
prompt-for-this is a reminder that a secret is missing. It is not a password, a token, or a key you save. The real secret stays in the password store. If a draft, a log, or a ticket still contains a live secret, stop and rotate it. Then delete the copy.
One change. A firewall, a detection, a DNS record, and a policy do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous value, written down while the system still works.
A second person reads the scope aloud: which host, which domain, which account. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.
Documentation addresses stay in the lab. 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 are not your production network. example.com is not your domain. Replace them before a real record or a real rule is published.
Do not allow every address because a test failed. A rule, a header, or a detection that matches the world is a draft you delete. Management stays on the prefix you named. A service port opens when the service is ready, for the clients you named.
Keep the previous file. A generator draft is not the previous file. The previous file is what you reload if the new one is wrong. You practised the reload on the lab, with a console or a second session open when the change can lock you out.
If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied config produces a system nobody can explain. Rebuild the lab from the copy you kept.
When the checks pass, the next system waits until someone else can repeat the proof from the notes. DevSecOps is done for this window when the proof is written, not when the tool printed a file.
This page is a planning guide. It is not legal advice, not an audit opinion, not a vendor manual, and not the text of a standard. If a lawyer, an auditor, or a regulator must see the decision, they see the ticket and the evidence, not this paragraph.
Hand the finished note to the neighbouring guide that owns the next step, and leave this system alone until that guide has its own window.
Pipeline checks before the gate is required
Confirm this before you call the change done: The repository is one you administer. The lab secret was fake. The build failed on it. The build passed after removal. Any real secret was rotated and not printed. The exception path is written. The check is required on the default branch only. Scanner scope is your code. Build logs were checked for secrets. A second person saw the fail and the pass. The previous pipeline file is saved. No second gate was added. The hostname in the prompt matches the hostname in the ticket for DevSecOps. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for DevSecOps happened, and the next host is not started early. If one of those fails, stop.
Tools for this guide
These tools run in the browser on this site. They do not log into your machines.
Related pillar guides
Guides in this cluster
These supporting pages belong to this pillar.
- How-To: Finding Secrets in Code
- Checklist: Container Security Best Practices
- How-To: Threat Modeling with STRIDE
Companion: Cloud: Infrastructure as Code Guide.