DevSecOps: where to start if development is already underway

The phrase “we need DevSecOps” usually means “we need a scanner.” They will buy a scanner, it will find four thousand comments, the development will ignore them, and after six months the project will be closed as a failure. The error is not in the tool: defects were looked for in the same place as before - at the end, just faster.

The practical meaning of DevSecOps is the same: the check is performed at a time when its result is still cheap to apply. The secret found in the commit is thirty seconds of work. The same secret found in the product - key rotation, access analysis and explanation with the customer. The difference is not in the quality of the search, but in the moment.

If development is already underway, you can’t introduce everything at once - the conveyor will stop. The order below is proven to ensure that each step produces a measurable result before the next one begins.

Step 1. Inventory (1–2 weeks)

List of repositories, pipelines, environments and exit points. Who is the owner, what is deployed where, what external addresses are open. Without this map, any automation covers a random subset. The outer part of the perimeter is convenient to remove audit of external assets — Forgotten stands with combat data regularly surface.

Step 2. Secrets (2–3 weeks)

The fastest victory. The search for secrets is enabled on all repositories at once, the history is scanned in a separate run, the found keys are rotated, and storage moves to the secrets manager. Here we also put things in order in the accounts of the conveyor itself: assembly agents almost always have excessive rights - a topic IDM/PAM and access control.

Step 3. Delivery contents (3–4 weeks)

SCA and SBOM: You start to know what the product is made of. This is at the same time safety, licensing purity and the basis for import substitution - without the composition of the supply, talk about technological independence is pointless (import substitution and technological independence).

Step 4. Code analysis and dynamics (1–2 months)

SAST is enabled in the “new defects only” mode, DAST is enabled on the test environment. Rules for blocking the build and SLA for correction also appear here. Manual analysis and pentest They are connected last: they are expensive and meaningful when the automation has already removed the noise.

The main reason for the failure is the flow of finds that cannot be processed. Working techniques:

• Baseline. Everything that is found in the first run is recorded as a known debt and is not blocked. Only new defects are blocked—those that were not present in the previous build. Otherwise, the team gets a stopcock on the first day.
• Thresholds are based on criticality, not quantity. “No more than 10 comments” is a meaningless rule. “No new critical vulnerabilities in the modified code” - executable.
• SLA for correction instead of instant blocking. Critical - 3 days, high - 14, medium - in the planned release. Delays are escalated rather than stopping the pipeline.
• One tracker. Security defects live in the same place as other development tasks. No one reads a separate “vulnerability register” except the one who maintains it.
• Dealing with false positives. The team should have an easy way to mark a find as not applicable with justification—and that decision should be maintained between runs. Without this, confidence in the tool is lost within two weeks.
• A safety on the team, not above it. The Security Champion within the development team resolves 80% of issues on the spot.

• GOST R 56939 “Developing secure software” sets the framework of processes: security requirements analysis, threat modeling, static analysis, testing, configuration management. For many customers, compliance with this standard is a condition of acceptance.
• Significant CII objects. If the software operates within a significant facility, the requirements under Federal Law No. 187-FZ are added to the development process - see. "Protection of CII / Federal Law No. 187-FZ".
• Register of Russian software. To enable it, you need a confirmed supply and dependency control - what SBOM provides from step 3.
• Personal data in test environments. A copy of the combat base on the stand is a typical and gross violation of Federal Law No. 152-FZ. Is being decided masking and depersonalization, not a ban on testing.

Days 1–30

• A register of repositories, pipelines and environments with owners has been compiled.
• The search for secrets is enabled on all repositories, the history has been scanned.
• The found keys were rotated, storage moved to the secrets manager.
• The rights of assembly agents have been revised and curtailed.

Days 31–60

• SCA runs on every build, SBOM is saved as a release artifact.
• The criticality blocking thresholds were determined and the baseline was recorded.
• Security defects are included in the general development tracker.
• Remediation SLAs and escalation procedures have been agreed upon.

Days 61–90

• SAST is enabled in “new defects only” mode on key repositories.
• Container scanning and infrastructure manifest checking are built into the pipeline.
• DAST works on the test environment at least for external services.
• Security champions have been appointed, the first summary of metrics has been collected.