How a fixed-fee pipeline assessment traces one code change from commit to production, baselines DORA metrics, inventories the tooling an agency already owns and has authorized, and delivers a target pipeline design and a fixed-price stand-up plan, with control mapping the ISSM can use.
Most federal application teams already own a modern build tool. GitLab, GitHub Enterprise, Jenkins or Azure DevOps sits in the enterprise license, and releases still happen on a weekend, by hand, from a checklist one engineer keeps in their head. Security scans run the week before an assessment. The ATO evidence is a folder of screenshots. A one-line fix takes weeks to reach production, and nobody can say exactly where the weeks go.
Owning the tool is not the same as having the capability. A working pipeline builds, tests, scans and deploys every change the same way, enforces the approvals change control requires, and records each step as evidence.
This paper is for the people who carry that problem: program managers who own the mission software and the budget, CIO development and platform leads, ISSMs and ISSOs who must approve every tool, connection and gate, CISOs, and the CORs who buy the work. It describes Avalon Technology Services' CI/CD Pipelines service, which starts with one engagement:
Section 9 works through an illustrative application. One change takes 40 calendar days from commit to production, but only 7.75 days of hands-on work (19% flow efficiency). 40% of the elapsed time sits in steps a pipeline can execute or record. 55% sits in the change board and the deployment window, which no tool fixes: that part needs a change-control decision by the government.
The service builds and documents. It implements automated enforcement and evidence for the controls the pipeline touches. The agency's assessor assesses those controls, and the Authorizing Official (AO) decides.
The same phrases come up in almost every conversation about a federal application team's release process. Any two of them together usually mean the delivery path, not the code, is the constraint.
| What the team says | What it usually means |
|---|---|
| "We deploy quarterly" or "release weekends" | Changes are batched because each release is expensive, which makes each release riskier |
| "Three weeks to get a one-line change to production" | Calendar time is spent waiting in queues, not in work |
| "The scans get run right before the assessment" | Security testing is an event, not a gate, so findings arrive late and in bulk |
| "Our ATO evidence is screenshots" | Change control happens, but nothing records it in a form an assessor can test |
| "We have GitLab but we're barely using it" | The license was bought; the pipeline engineering was never funded |
| "We keep getting written up on change control" | CM-family findings on baselines, approvals or access restrictions for change |
| Driver | What it says | What it means for this engagement |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CM, SA, SI, RA, AU and SR controls on change control, developer testing, flaw remediation and supply chain | The control IDs each pipeline stage is mapped to |
| OMB M-26-05 (Jan 23, 2026) | Rescinded M-22-18 and M-23-16; agencies set risk-based software assurance policies | SSDF (SP 800-218) is guidance an agency may adopt; SBOMs are a contract term it may choose |
| NIST SP 800-218 and SP 800-204C | Secure software development practices and DevSecOps implementation guidance | Design references, not mandates; the pipeline produces SSDF-aligned evidence |
| DoD cATO memo (Feb 2, 2022) | Continuous authorization rests on ongoing monitoring, supply chain security and DevSecOps practice | An instrumented pipeline positions a program for continuous-authorization approaches; it does not achieve one |
| DoD CSRMC (Sep 24, 2025) | A new DoD cybersecurity risk management construct; RMF, DoDI 8510.01 and eMASS remain in use | Evidence is shaped for the authorization process the program actually uses |
| OMB M-26-14 (May 2026) | A risk-based logging model; replaced M-21-31 | Pipeline event logs go to the agency SIEM according to the agency's logging decisions |
| CISA BOD 26-04 (Jun 10, 2026) | Risk-based remediation clocks for known exploited vulnerabilities; replaced BOD 22-01 | A repeatable release path is how SI-2 fixes reach production inside the clock |
| FedRAMP Consolidated Rules (Jun 25, 2026) | Offerings are "FedRAMP Certified" in classes A through D; certification covers the provider's offering only | SaaS pipeline tooling must be certified or hosted inside the system boundary |
The engagement gets bought at predictable moments: an assessment or ATO renewal that produced CM-family or SI-2 findings; a hard mission date that development will hit but release logistics will miss; a cloud migration, where the new environment should start with a pipeline rather than inherit the old release process; leadership direction toward continuous authorization; an outage traced to a manual deployment; a contractor transition; and fourth-quarter funds, July through September, looking for a fixed-price, fast-start task.
The assessment answers three questions for one application team: where a change spends its time between commit and production, what the agency already owns and has authorized, and what a pipeline built from those parts should look like. It works in the agency's tooling and does not select or buy new tools.
| Step | Activities |
|---|---|
| Kickoff and access | Read access to repositories, tickets and change records agreed; government dependencies dated in writing; the pilot application and team named |
| Value-stream trace | One recent change followed from commit to production through review, build, test, scans, change board, deployment and evidence capture, with calendar and hands-on time per step |
| Metrics baseline | Deployment frequency, lead time for changes, change failure rate and time to restore, from the agency's own records |
| Toolchain and authorization inventory | What is licensed, what is installed, what the ISSM has authorized, and where SaaS tooling sits relative to the system boundary |
| Target design | Stages, environment promotion model, branching, secrets handling, runner placement, approval gates and separation of duties matched to the agency's change control policy |
| Stand-up SOW and readout | A fixed-price statement of work for the build, with per-application options, and a briefing to the program manager, ISSM and platform lead |
| Deliverable | Format |
|---|---|
| Current-state assessment with the commit-to-production trace | Markdown or PDF, with diagrams |
| DORA metrics baseline | Spreadsheet with method notes |
| Toolchain and authorization inventory | Spreadsheet |
| Target pipeline architecture | Markdown or PDF, with diagrams |
| Draft control-mapping matrix (pipeline stage to 800-53 control) | Spreadsheet, written for an SSP appendix |
| Fixed-price stand-up statement of work with per-application options | Word or PDF |
| Readout | Slide deck and live briefing |
The engagement does not select or procure security tools or design a security program (Avalon's separate DevSecOps service), refactor or containerize the application, write or fix test suites, or build the landing zone or Kubernetes platform the pipeline deploys into (Cloud Architecture & Engineering, Cloud Migration & Development). It does not write the SSP, run the assessment or facilitate the ATO; the control-mapping matrix is a handoff to whoever does. It does not resell licenses or operate releases after handoff.
A pipeline moves a set of controls from manually performed and manually evidenced to enforced in tooling and recorded automatically. The target design maps each stage to the controls it supports so the ISSM can see the contribution before anything is built.
| Pipeline stage | Controls supported | What it records |
|---|---|---|
| Protected branches and enforced review | CM-2, CM-3, CM-5, SA-10 | Baseline, change approvals and who can change what |
| Automated build with signed, versioned artifacts | CM-14, SI-7 | Component signing and integrity checks |
| Automated test execution as a gate | SA-11, CM-4 | Test results and change impact per release |
| SAST, dependency, secrets and container scanning gates | RA-5, SA-11, SA-15 | Scan results against thresholds the ISSM approved |
| SBOM per build, where the agency requires it | SR-3, SR-4, CM-8 | Component inventory and provenance |
| Approval-gated deployment | CM-3, CM-5 | Separation of duties on production change |
| Pipeline logs to the agency SIEM | AU-2, AU-6, AU-12, CA-7 | Audit records and a continuous monitoring feed |
| Repeatable release path | SI-2 | Dated evidence of how fast fixes reach production |
This paper names the matrix as a handoff and stops there. Turning pipeline evidence into an authorization package and ongoing monitoring is the subject of Avalon's separate NIST RMF Implementation service.
| Accurate | Not accurate |
|---|---|
| Implements automated enforcement and evidence for CM, SA, SI, RA and AU controls | Makes the system compliant with NIST 800-53 |
| Positions the program for continuous-authorization approaches | Achieves cATO |
| Produces SSDF-aligned development evidence and per-build SBOMs | Certifies SSDF conformance |
| Reduces assessment preparation for the controls the pipeline touches | Guarantees a clean assessment or speeds an ATO |
| Phase | Timing | What happens |
|---|---|---|
| Access lead | 2–6 weeks, on the agency's clock | CAC or PIV, VPN and firewall approvals; the SOW ties the schedule to these dependencies |
| Trace and baseline | Week 1 | Value-stream trace, DORA baseline, toolchain and authorization inventory |
| Target design | Week 2 | Architecture, gates and promotion model worked through with the ISSM and the pilot team |
| SOW and readout | Week 3 | Draft deliverables, five-business-day agency review, final briefing |
| Stand-up follow-on (separate) | 10–12 weeks | Assess and design (1–2), build (3–7), harden and wire evidence (8–10), pilot, transfer and close (11–12) |
| Included | Separate work |
|---|---|
| Integrating scan tools the agency already approved | Selecting or procuring security tools |
| Running the team's existing tests in the pipeline | Writing or fixing test suites |
| Deploying to environments the agency provides | Building the landing zone or Kubernetes platform |
| A control-mapping matrix for the SSP author | Writing the SSP or the authorization package |
| Runbooks and training at handoff | Operating releases after handoff |
| Working in licensed agency tooling | License resale or hosted tooling |
| Unclassified environments | Classified or air-gapped environments |
Avalon takes one engagement at a time, works business hours, and works in unclassified environments only. Avalon's founder manages the engagement. The technical lead is one named, certified senior platform engineer, hired or subcontracted for the engagement and listed in the proposal; without that person confirmed, Avalon does not bid. Avalon has no past federal engagements under this service. FAR 15.305 says an offeror without a record of past performance may not be evaluated favorably or unfavorably on that factor; what protects the agency is a named lead, a fixed price and a bounded scope. Avalon never assesses its own work and will sign an organizational conflict of interest representation.
| Requirement | How it is handled |
|---|---|
| Senior platform engineer | Named personnel whose certifications and investigation level match the agency's requirements, listed in the proposal, hired or subcontracted |
| Cloud, Kubernetes or toolchain credentials | Required on the named engineer where the agency's environment calls for them, as a condition of the engagement |
| DoD privileged access | A DoD 8140-qualified named engineer where the work needs privileged access, as a condition of award |
| Civilian and DoD access | Public Trust or other investigation at the level the agency requires, as a condition of the engagement |
| Hardened images | Where the agency's environment uses Iron Bank or other hardened images, the design uses them; Avalon has no onboarding of its own |
| Insurance and contract vehicles | Any coverage the solicitation requires is a condition of award; Avalon does not hold a GSA Schedule or a governmentwide contract today |
| Engagement | Market-norm range | Avalon |
|---|---|---|
| Pipeline assessment and target design, one application team, 3 billable weeks | $25K–$50K FFP | Firm fixed price; illustrative $34K |
| Standalone stand-up, unclassified, 1–3 named pilot apps, 10–12 weeks | $120K–$350K FFP | Firm fixed price from the design, with per-app options |
| Pipeline line item inside a larger modernization or DevSecOps effort | $60K–$250K | As a subcontractor to the prime |
| Post-handoff support | Scoped hours pool | Business hours only; no response-time commitment |
The assessment and the stand-up both sit under the $350,000 simplified acquisition threshold, so both can be bought as open-market purchases. Purchases between the $15,000 micro-purchase threshold and the SAT are generally set aside for small business when two or more capable small businesses are expected to compete. Pipeline work inside a larger modernization task order can be subcontracted to Avalon by the prime. Avalon does not hold a GSA Schedule or a governmentwide contract today, and it does not resell licenses.
The stand-up is priced as a firm fixed base for the named pilot applications plus priced options for each additional application. Once the templates exist, a further application is days of work, not weeks, and an application with no automated tests or a fragile build is priced on its own line rather than absorbed. Labor categories carry the same rates across every line item.
The figures below are a planning illustration for one representative application team that releases through a monthly change board. They are assumptions, not measurements from any agency and not results from any engagement. A real trace replaces every number.
| Step | Calendar days | Hands-on days | Share of lead time | Who can change it |
|---|---|---|---|---|
| Code review and merge | 2 | 0.5 | 5% | Team practice |
| Manual build | 1 | 0.5 | 2% | Pipeline can execute or record |
| Manual test cycle | 8 | 3 | 20% | Pipeline can execute or record |
| Pre-release security scans | 4 | 1 | 10% | Pipeline can execute or record |
| Change advisory board wait | 15 | 0.25 | 38% | Change-control policy |
| Deployment window wait and release | 7 | 1 | 18% | Change-control policy |
| Evidence capture (screenshots, tickets) | 3 | 1.5 | 8% | Pipeline can execute or record |
| Total | 40 | 7.75 | 100% | Flow efficiency 19% |
Only 7.75 of the 40 days are work. The rest is waiting. The steps a pipeline can execute or record (build, test execution, scans and evidence capture) account for 16 days, or 40% of lead time. The change board wait and the deployment window account for 22 days, or 55%, and no pipeline changes them. Review and merge is 5%, and depends on team habits the pipeline can enforce but not create.
That split is usually the most useful finding in the readout. It tells the program manager which delays an engineering investment can address and which need a decision from the people who own change control. The manual test cycle only shrinks if automated tests exist, and writing them is the team's work.
| Change board cadence | Average wait (days) | Lead time (days) | Policy-bound share |
|---|---|---|---|
| Monthly CAB (base) | 15 | 40 | 55% |
| Biweekly CAB | 7 | 32 | 44% |
| Weekly CAB | 3.5 | 28.5 | 37% |
Holding every other step constant, moving from a monthly to a biweekly board takes lead time from 40 to 32 days, and a weekly board takes it to 28.5. Even then, 37% of the time is policy-bound. Pre-approving standard changes that pass the pipeline's gates is a government decision; the pipeline produces the record that makes it defensible.
| Scope | Rate-band range | Planning fee | Fits $25K–$50K |
|---|---|---|---|
| One app, 3 weeks (recommended) | $27.9K–$40.1K | $34K | Yes |
| One app, 4 weeks | $37.2K–$53.4K | $45K | No: cap scope |
| Two apps, 3 weeks | $36.0K–$51.2K | $44K | No: cap scope |
The base case is three billable weeks: a senior platform engineer full time at $185 to $260 an hour, a compliance specialist at one quarter time and a project manager at 10% to 15%, both at an assumed $135 to $185 (the knowledge base lists no separate rate for either). That is $27.9K to $40.1K, with a $34K planning fee. A fourth week runs $37.2K to $53.4K, past the top of the band at the high rates. A second application adds a half-time infrastructure engineer, for $36.0K to $51.2K, also at the edge. So the recommended scope is one application, three weeks, with the two to six week access lead on the agency's clock.
For the stand-up follow-on, the knowledge base staffing (senior engineer at 0.75 to 1.0, infrastructure engineer at 0.5, compliance at 0.15 to 0.25, project manager at 0.1 to 0.15) over 10 to 12 weeks computes to about $96K to $205K in labor before per-application options. The firm fixed price is set from the target design and the named applications.
| Pitfall | How to avoid it |
|---|---|
| The pipeline becomes "fix the application" | Name application refactoring and test authorship as out of scope in the SOW |
| Application count creep | Name the pilot applications; price additional ones as options |
| Platform creep | Target environments are government-furnished; the landing zone is separate work |
| The ISSM arrives in week ten | ISSM in from week one; every gate agreed before it is built |
| Access issuance slips | Date it as a government-furnished dependency; the schedule moves day for day |
| License entanglement | Work only in licensed, authorized agency tooling; no resale |
| Inconsistent rates across line items | Same labor categories, same rates, in every line of a bundled proposal |
| Overselling the result | Use the accurate phrasing; the assessor assesses and the AO decides |
A release weekend is not a scheduling problem. It is a finding: the delivery path depends on manual steps, batched changes and evidence nobody records as it happens. Most agencies already own the tools to fix the engineering part. What they lack is a clear picture of where the time goes, which part belongs to change control, and a fixed price for building the pipeline in what they already have.
The natural first step is the fixed-fee pipeline assessment and target design: one application team, three billable weeks, under the simplified acquisition threshold, ending in a commit-to-production trace, a DORA baseline, a target architecture the ISSM has seen, a draft control-mapping matrix and a fixed-price statement of work for the stand-up. To discuss an application team, contact Avalon Technology Services at contact@AvalonTechServices.com.
CAB
Change advisory board: the group that approves production changes under the agency's change control policy.
cATO
Continuous authorization to operate: a DoD approach, described in the February 2022 DoD CIO memo, that relies on ongoing monitoring and DevSecOps practice.
CI/CD
Continuous integration and continuous delivery: building, testing and preparing every change for release automatically, with deployment gated by defined approvals.
DORA metrics
Deployment frequency, lead time for changes, change failure rate and time to restore service, from the DevOps Research and Assessment program.
Flow efficiency
Hands-on work time divided by total elapsed time for a change.
Pipeline as code
Pipeline definitions stored and versioned in the repository alongside the application.
SBOM
Software bill of materials: a machine-readable list of the components in a build, in SPDX or CycloneDX format.
SSDF
NIST SP 800-218, the Secure Software Development Framework.
All values are planning assumptions for one representative application team. None is drawn from a specific agency, a measured pipeline or a completed engagement.
| Assumption | Value | Basis |
|---|---|---|
| Commit-to-production steps | Seven steps, 40 calendar days, 7.75 hands-on days | Planning assumption |
| Change board | Monthly, 15-day average wait; biweekly 7; weekly 3.5 | Half the interval between meetings, rounded |
| Step classes | Pipeline can execute or record; team practice; change-control policy | Assigned per step for the illustration |
| Assessment staffing | Senior engineer 1.0, compliance 0.25, PM 0.10–0.15; second app adds 0.5 infrastructure | 40 hours a week |
| Rates | Senior $185–$260; mid-level $135–$185 an hour | Market-norm estimates; compliance and PM assumed mid-level |
| Price check | Base fee $34K | Inside the $25K–$50K band |
