What is the difference between software version control and software configuration management in defense programs?

Version control (Git, SVN, ClearCase) is one tool within the broader discipline of software configuration management (SCM). SCM in defense programs encompasses far more: the formal identification of configuration items (CIs) across software, hardware, documentation, and interfaces; the establishment and control of baselines; the structured process for evaluating and approving changes through a Change Control Board (CCB); and the auditable records that prove the delivered product matches its approved baseline. MIL-STD-973 defines SCM as a management discipline, not a tooling discipline. A team can use Git perfectly and still fail an SCM audit if it lacks a Configuration Management Plan, cannot demonstrate baseline traceability, or has no documented CCB charter. In safety-critical aviation software governed by DO-178C, the SCM process must be formally defined in the Software Configuration Management Plan (SCMP), reviewed by the certifying authority, and evidenced in the Software Life Cycle Data deliverables. Version control is a necessary but far from sufficient condition for compliant defense SCM.

When is the Functional Baseline established, and what does it control?

The Functional Baseline (FBL) is established upon acceptance of the system-level functional specification — typically the System/Subsystem Specification (SSS) produced during the Preliminary Design Review (PDR) phase. It defines what the system must do (performance, functional, and interface requirements) without prescribing the physical implementation. Once the FBL is established, any change to those requirements must go through the CCB via a formal Engineering Change Proposal. In a software-intensive defense program, the FBL controls the System Requirements Specification and the Interface Requirements Specification. Software teams care about the FBL because allocated requirements flow down from it: if the FBL changes and the software team was not notified through the CCB, the software's compliance matrix becomes invalid, which surfaces as a finding during the Functional Configuration Audit. Programs that skip or informally manage the FBL invariably discover during FCA that requirements were quietly modified without corresponding software changes — a common source of re-work and schedule slip at system integration.

What is the Allocated Baseline and how does it differ from the Functional Baseline?

The Allocated Baseline (ABL) is established at the Critical Design Review (CDR) and controls the allocation of system-level requirements to subsystems and configuration items. Where the Functional Baseline says 'the system shall detect targets at ranges up to 40 km with a probability of detection of 0.95,' the Allocated Baseline allocates portions of that requirement to specific hardware and software CIs — sensor hardware, signal processing firmware, track management software — with individual performance budgets for each. In practice the ABL is the development specification for each CI. It is the authoritative source for software requirements specifications (SRS documents) and for Interface Control Documents (ICDs) that govern the software-hardware boundary. Once the ABL is approved, it enters CCB control: adding, deleting, or modifying an allocated requirement is a Class I or Class II change depending on impact. Software teams should treat the ABL as the contract between the system engineer and the software developer — changes to it trigger re-analysis of software architecture, test coverage, and safety cases.

What makes a change Class I versus Class II, and who has authority to approve each?

The classification framework for Engineering Change Proposals derives from MIL-STD-973 and is refined in each program's Configuration Management Plan. A Class I change affects a formally controlled baseline, an approved deliverable, a contractual commitment, or a safety-critical requirement. Examples include: changes to system performance that alter the Functional Baseline; changes that affect form, fit, or function as defined in the Product Baseline; changes that alter interface definitions in an approved ICD; and changes that affect software covered by a safety case or a DO-178C Data Package. Class I changes require CCB approval before implementation, and acquirer (government program office or customer) concurrence is typically required. A Class II change is internal to the contractor's technical design — it does not affect a controlled baseline, a contractual deliverable, or an approved interface. Class II changes are approved by the contractor's internal CCB without acquirer involvement, though they are recorded and available for review during configuration audits. The boundary between Class I and Class II is a frequent source of disagreement and should be explicitly defined in the CMP with worked examples, not left to individual engineers' judgment.

How should a CCB be structured for a mid-sized defense software program?

A CCB for a mid-sized program (20–100 engineers, 2–5 major software CIs) typically includes a permanent chair (chief engineer or program manager), a secretary who maintains meeting minutes and action items, and standing voting members representing systems engineering, software, hardware, test, logistics/ILS, and the configuration management office. For Class I changes, the program office representative (government PM or contracting officer technical representative) may attend or provide written concurrence. Non-voting participants include the originator of the ECP, affected subsystem leads, and cost/schedule analysts. The CCB charter — a controlled document itself — defines quorum requirements, voting rules (majority, supermajority, or consensus depending on impact), conflict-of-interest recusals, and the escalation path for tied votes. Meeting cadence for most programs is weekly for routine changes and on-demand for emergencies. The secretary publishes draft minutes within 48 hours and final minutes within five business days, both of which become controlled documents filed in the Configuration Management Database.

What records must be retained to satisfy a MIL-STD-973 configuration audit?

MIL-STD-973 defines two formal audits: the Functional Configuration Audit (FCA) and the Physical Configuration Audit (PCA). For the FCA, records that must be available include: the approved functional specification (FBL document), all approved ECPs that modified it, the software requirements specification and its traceability matrix mapping each requirement to test cases, the completed test reports showing successful test execution for every FBL requirement, and open-item logs with disposition records. For the PCA, required records include: the Product Baseline document or build specification, the bill of materials or software version description (SVD) for every CI in the delivered configuration, build reproduction records demonstrating that the delivered binary can be rebuilt from the controlled source baseline, and any as-built deviations or waivers approved by the acquirer. In practice, programs that maintain a live traceability matrix in a requirements management tool (IBM DOORS, Jama Software, or equivalent) and that use a CMDB to link requirements to test results to source baselines are in a much stronger audit posture than programs that reconstruct these records from email and shared drives at audit time.

How does DO-178C Software Configuration Management differ from MIL-STD-973?

DO-178C Section 7 addresses Software Configuration Management and applies to airborne software — avionics, weapon system flight software, mission computers — certified under FAA or EASA processes. MIL-STD-973 applies to all configuration items across a defense system, not just software, and governs the contractual relationship between contractor and government acquirer. The two standards are complementary but have different emphasis. DO-178C requires a formal Software Configuration Management Plan (SCMP) that is a compliance artifact reviewed by the DER or certification authority. It demands that every Software Life Cycle Data item (SRS, SDD, test cases, test results, source code, executables) be placed under configuration control, that changes be formally managed, and that the problem reporting and change control process be documented and followed. Critically, DO-178C requires tool qualification for any SCM tool that produces outputs used as certification evidence — if your version control system generates the baseline label that appears in the Software Version Description deliverable, that tool requires a Tool Qualification Plan (TQP). MIL-STD-973 does not have an equivalent tool qualification requirement, though CMDB tools used for contractor data item deliveries often require qualification or validation to satisfy data integrity requirements in the CDRL.

What is a Configuration Management Database (CMDB) and how does it differ from a simple version control repository?

A CMDB is a structured data store that tracks configuration items, their attributes, their relationships to each other, and their status across the configuration lifecycle. A version control repository tracks changes to file content over time. The CMDB answers different questions: What is the approved build configuration for software version 3.2? Which CIs are affected by ECP-047? What is the configuration status of each CI in the fielded system at Serial Number 0012? What changes have been made since the last PCA? In defense programs, the CMDB often integrates with requirements management tools, test management systems, and defect trackers to provide end-to-end traceability. In air-gapped environments — common for classified programs — the CMDB must be hosted on-premises; common choices include Jira with a configuration management plugin, PTC Windchill, or IBM Engineering Lifecycle Management (ELM). The CMDB is a primary evidence source during FCA and PCA audits, so its data integrity (access controls, change logging, backup) must itself be formally managed.

How does emergency change control work when a critical defect is found in a fielded defense system?

Emergency change procedures are defined in the CCB charter and the CMP before they are needed — improvising them during a crisis leads to undocumented changes that become audit findings. A typical emergency change procedure has four phases. In the authorization phase, the originator declares an emergency change and gets verbal or email authorization from the CCB chair and — for Class I changes — the program office representative; this temporary authorization is time-limited, typically 24–72 hours. In the implementation phase, the change is made under normal version control discipline by designated personnel — emergency does not mean skipping documentation. In the ratification phase, a full ECP is prepared and submitted to the next scheduled CCB meeting for formal approval; the CCB votes to ratify (or reject) the emergency action. In the audit closure phase, the CMDB is updated, the baseline is re-labeled, and the emergency action record is closed with references to the ratifying CCB minutes. Programs that allow emergency changes to remain unratified beyond one CCB cycle are building technical debt in their configuration audit trail that becomes very expensive to clear during PCA.

What are the CDRLs related to configuration management that a defense contractor typically delivers?

Contract Data Requirements Lists (CDRLs) for configuration management vary by contract type and program phase, but a typical set includes: the Configuration Management Plan (CMP), which is the master document governing how SCM will be implemented across the program; the Configuration Status Accounting Report, a periodic (monthly or quarterly) summary of CI status, open ECPs, and waiver/deviation activity; the Engineering Change Proposal itself, submitted per change event; the Software Version Description (SVD), delivered with each software release and identifying the exact source baseline, build environment, and known anomalies; and the Interface Control Document (ICD), maintained under CCB control for each external interface. For programs with DO-178C obligations, the Software Configuration Management Plan is a separate CDRL from the system-level CMP and must demonstrate compliance with DO-178C Section 7. Programs using data rights clauses (DFARS 252.227-7013/7014) must also track and deliver configuration data with appropriate markings indicating government and contractor rights, which is itself a configuration management discipline.

How should an SCM tool be qualified under DO-178C for use in airborne software development?

DO-178C section 12.2 and DO-330 (the Software Tool Qualification standard) define the qualification requirements. A tool requires qualification when it is a Development Tool — one whose output is part of the airborne software or whose failure could introduce an error not detected by the development or verification process. For SCM tools specifically: a version control system whose labeled baseline is used to generate the code archive delivered as certification evidence is a Development Tool and requires qualification to DO-330 criteria TD3 (the lowest tier, but still requiring a Tool Qualification Plan, documented tool operational requirements, and validation that the tool correctly implements those requirements). The qualification evidence includes: Tool Operational Requirements (TOR) stating what the tool must do, a Tool Qualification Plan, tool testing records demonstrating correct operation, and a Problem Report process for the tool itself. In practice, most programs qualify the SCM tool at a system level — demonstrating that the repository correctly stores and retrieves the exact byte sequence submitted — rather than attempting to qualify the tool against a specific commercial product version, which would require requalification on every upgrade.

Configuration management for defense software

Software configuration management in a commercial context is largely synonymous with version control. In defense programs, version control is the least of your SCM obligations. The real discipline encompasses formal baseline establishment, a functioning Change Control Board, documented engineering change proposals, configuration status accounting reports, and configuration audits that a government representative must be able to walk into and verify. Miss any of those elements and you risk contract findings, schedule slips at system integration, and failed audits that stop deliveries. This guide covers each element in sequence — what it means, how to implement it correctly, and where programs typically fail.

What configuration management means in defense programs

Configuration management in the defense context is a management discipline defined by MIL-STD-973 and its civilian equivalents (EIA-649, ISO 10007). It spans four core functions: configuration identification (what are the controlled items and their attributes?), configuration control (how are changes evaluated and approved?), configuration status accounting (what is the current approved state of each item?), and configuration verification and audit (does the product match its approved baseline?).

The scope extends well beyond source code. A defense system's configuration items (CIs) include hardware assemblies, printed circuit boards, firmware images, software executables, technical manuals, test procedures, interface control documents, and even support equipment. Each CI is formally designated with a unique identifier, an owning engineering discipline, and a documented parent-child relationship to the system-level CI tree. Changing any CI's attributes — its performance specification, its interface definition, its part number — triggers the configuration control process.

For software teams, the practical implication is that SCM is not owned solely by the software group. The defense software agile challenges that arise from concurrent hardware and software development are fundamentally a configuration management problem: when hardware CIs change their interface specifications, software CIs must be notified and updated through a formal process, not through an ad-hoc Slack message. The interface control document (ICD) is a controlled item; changes to it require an approved Engineering Change Proposal before any implementation begins.

This breadth is why defense programs maintain a dedicated Configuration Management Office (CMO) staffed by specialists, rather than assigning SCM responsibilities to a developer as a part-time duty. The CMO maintains the Configuration Management Database, prepares and chairs the CCB, tracks all open ECPs, and prepares for configuration audits. On programs smaller than 50 people the CMO may be a single person — but it must be a person, with dedicated time, not a committee with no clear owner.

Baseline types and their lifecycle

MIL-STD-973 defines three formal baseline types that mark milestones in the system development lifecycle. Each baseline is a controlled snapshot of the approved technical documentation for the system or a CI at a defined point in the program.

Baseline	Established at	Controls	Key documents
Functional Baseline (FBL)	PDR acceptance	What the system must do	SSS, Interface Requirements Specification
Allocated Baseline (ABL)	CDR acceptance	Requirements allocated to each CI	Software Requirements Specification, ICDs, development spec per CI
Product Baseline (PBL)	Physical Configuration Audit	The as-built product ready for delivery	Build specification, Software Version Description, BOM

Functional Baseline. The FBL is established when the government accepts the system-level functional specification at PDR. It captures what the system must do — performance, functional, and interface requirements — without specifying how. Once closed, changes to the FBL require a Class I ECP and government concurrence. Software teams discover FBL changes most painfully during Functional Configuration Audits, when requirements they were never formally notified of appear on the audit checklist.

Allocated Baseline. The ABL closes at CDR and controls how system-level requirements are distributed across CIs. Each software CI's Software Requirements Specification (SRS) traces to the ABL. If a system requirement is subsequently reapportioned — say, a timing requirement shifts from a hardware CI to a software CI — that reapportionment is a Class I change requiring CCB approval and SRS revision before the software team changes a single line of code. Programs that allow informal re-apportionment in engineering hallway conversations end up with an SRS that reflects actual implementation rather than approved requirements, which fails FCA every time.

Product Baseline. The PBL is the culmination of the development process, established after the Physical Configuration Audit confirms that the delivered product matches its documented configuration. The PBL includes the build specification (exact source version, compiler, tool chain, and build parameters needed to reproduce the deliverable), the Software Version Description, and the as-built bill of materials. Once the PBL is established, the product enters sustainment configuration control — all changes, however small, require formal ECPs through the CCB.

Change control board structure and operations

The CCB is the decision-making body that evaluates proposed changes to controlled baselines. It is not a review board or a technical advisory group — it is a formal authority with documented charter, defined membership, and binding voting rules. A CCB that operates informally, that makes decisions in ad-hoc email threads rather than formal meetings with recorded minutes, is not a CCB in the MIL-STD-973 sense and will not satisfy a government audit.

Charter. The CCB charter is a controlled document (itself managed under SCM) that defines: the CCB's authority and scope; standing membership and alternates; quorum requirements (typically a majority of voting members); voting rules for routine changes, controversial changes, and emergency procedures; the ECP submission format and required supporting information; decision timelines (e.g., routine ECPs decided within 10 business days of submission); and the escalation path when the CCB cannot reach a decision.

Composition for a mid-sized program. A CCB for a 30–100 person defense software program typically includes:

Chair: Chief Engineer or Program Manager — tie-breaking vote, ensures adherence to charter
Secretary: Configuration Management Officer — prepares agendas, records minutes, maintains CMDB
Voting members: Systems Engineering lead, Software lead, Hardware lead, Test lead, ILS/Logistics representative
Non-voting participants: ECP originator, affected subsystem leads, Cost/Schedule analyst
Government representative: COTR or PM — required for Class I changes, may attend or provide written concurrence

Meeting cadence. Most programs run weekly CCB meetings for routine changes, with a standing agenda that includes: status of previously approved ECPs; new ECPs submitted since last meeting (brief initial review); full presentations and votes on ECPs ready for decision; and emergency change ratifications. Emergency changes are authorized out-of-band by the CCB chair (and government representative for Class I) and ratified at the next scheduled CCB meeting — the ratification record closes the emergency authorization.

Minutes and records. Draft minutes must be distributed within 48 hours of the meeting and finalized within five business days. Minutes record: attendees, quorum status, ECPs reviewed with decision and vote tallies, action items with owners and due dates, and any dissenting views on controversial decisions. Minutes are controlled documents filed in the CMDB. The CM secretary's consistency in producing and filing minutes is one of the most significant factors in how prepared a program is for a configuration audit.

Engineering change proposals: class I vs class II

An Engineering Change Proposal (ECP) is the formal vehicle for proposing, evaluating, and approving changes to a controlled baseline. Every change to a configuration-controlled item that would affect the FBL, ABL, or PBL must be documented in an ECP before implementation begins — not after.

Class I vs Class II. The distinction determines who approves the change and how much process it requires:

Class I: Affects a formally controlled baseline, a contractual commitment, an approved interface (ICD), a safety-critical requirement, or form/fit/function of a deliverable. Requires CCB approval plus government concurrence. Implementation is blocked until approval is obtained. Typical examples: adding a new capability to the SRS, changing an ICD data field, modifying a safety requirement, deleting a test procedure from the approved test plan.
Class II: Internal technical change that does not affect any controlled baseline, contractual deliverable, or approved interface. Approved by the contractor's internal CCB without acquirer involvement. Recorded for audit trail but not subject to government review. Typical examples: refactoring internal module structure, changing a non-interface data structure, updating internal coding standards in a style guide that is not a CDRL.

The boundary between Class I and Class II is a frequent source of disagreement. The CMP must define this boundary with worked examples. A common pitfall is engineers independently deciding their change is Class II when it is actually Class I — changing the internal data format of a message that crosses a CI boundary is a Class I change even if the external interface (the ICD) appears unchanged, because the message format is an implicit interface.

Impact assessment. Every ECP requires a structured impact assessment before it can be voted on. The assessment covers: technical risk (what can go wrong with the proposed change?); schedule impact (how many days does this add to the schedule, including test regression?); cost impact (what is the estimated labor and material cost?); safety impact (does this change affect any safety-critical function or safety case assumption?); and interface impact (which other CIs, if any, must make corresponding changes?). For Class I changes, the impact assessment is prepared jointly by the originating engineer, the cost/schedule analyst, and the systems engineer. For changes with a safety impact, the safety engineer reviews and signs the assessment before CCB submission.

The ECP lifecycle: originator drafts ECP → CM secretary assigns number and logs in CMDB → CCB reviews at meeting → CCB votes (approve / reject / defer) → government concurrence obtained for Class I → ECP status updated to 'Approved for implementation' in CMDB → engineer implements change → version control commit tagged with ECP number → test evidence linked to ECP in CMDB → ECP closed. This complete audit trail — from origination through implementation and test evidence — is what government auditors look for during FCA and PCA. See also our guide on SBOM enforcement in defense pipelines, which intersects with ECP management for software supply chain changes.

Software configuration management toolchain

The SCM toolchain for a defense program must satisfy three constraints that do not apply in commercial development: the tools must be approvable under the program's Authority to Operate (ATO); they must support the formal traceability required by MIL-STD-973 and any applicable airworthiness standard; and — for most defense programs — they must operate in an air-gapped or partially air-gapped network environment.

Version control. Git is the de facto standard across unclassified and classified defense programs. For classified programs, self-hosted Git servers (GitLab Self-Managed, Bitbucket Data Center, or Gitea) are deployed within the accredited enclave. Branch protection rules enforce review requirements; signed commits provide non-repudiation for the audit trail. Repository naming conventions and branch naming conventions should be documented in the CMP and enforced through server-side hooks. For programs with DO-178C obligations, the version control system is a Tool Qualification candidate — the TQP must cover the specific server version, configuration, and the baseline-label operation that feeds the Software Version Description. For the broader context of running CI/CD in these environments, see our article on CI/CD for air-gapped defense.

Requirements management. IBM Engineering Requirements Management DOORS (classic and Next Generation) remains the most widely used requirements tool in defense programs, particularly those governed by MIL-STD-973 and DO-178C. Jama Software and PTC Windchill Requirements are common alternatives. The requirements tool must support bi-directional traceability (requirement → test case → test result) and must generate the traceability matrix artifacts required by the SDP/SCMP as CDRLs. The tool must itself be operated under configuration control: the requirement database is a configuration item, changes to requirements in the tool are change-controlled, and the tool's output must be reproducible from a labeled baseline.

Configuration Management Database. The CMDB tracks CI status, baseline associations, ECP records, waiver/deviation records, and configuration status accounting data. In large programs, the CMDB is often IBM Engineering Lifecycle Management (ELM) or a configured Jira instance with a CM plugin. Smaller programs sometimes use a disciplined Confluence + Jira combination. Whatever the choice, the CMDB must be in the accredited boundary, must have access controls that prevent unauthorized modification of approved records, and must generate the periodic Configuration Status Accounting Report that is a CDRL on most programs.

Air-gapped SCM server setup. The self-hosted Git server and CMDB are deployed on STIG-hardened RHEL instances inside the classified enclave. No connection to public repository hosting services. Package updates to the server software follow the program's media transfer procedure. The server's TLS certificates are issued by the program's internal PKI. Backups are stored in the enclave using encrypted storage with documented recovery procedures. Access to the version control server is governed by the program's access control list, with role-based permissions separating read, write, and administration access.

Configuration audits: FCA and PCA

Configuration audits are formal reviews conducted by or with government participation to verify that a CI or system meets its specified requirements (FCA) and that the product is accurately documented (PCA). They are not optional checkpoints — they are contract milestones that gate deliveries and payments.

Functional Configuration Audit (FCA). The FCA verifies that the software CI has satisfied all of its allocated requirements. The government audit team reviews: the approved SRS (ABL document) showing every requirement; the test procedures that test each requirement; the test results showing successful execution; the traceability matrix linking requirements to tests to results; and the open discrepancy reports showing all known anomalies and their resolution status. A common audit finding is requirements with no associated test — 'orphan requirements' that engineering teams meant to test but did not formally cover. Equally common is test procedures that claim to satisfy a requirement but actually test something adjacent to it — auditors read test procedures against requirements text literally. FCA preparation requires generating the traceability matrix from the requirements tool 60+ days in advance, reviewing it for gaps, and closing or documenting those gaps before the audit.

Physical Configuration Audit (PCA). The PCA verifies that the product to be delivered or fielded exactly matches its documented configuration. The core demonstration is build reproducibility: the contractor must show that, starting from the controlled source baseline identified in the Software Version Description, they can reproduce a binary that is byte-for-byte identical to the deliverable. This requires a complete build environment specification — not just the compiler version, but every tool in the build chain, every build flag, every environment variable that influences the output. Programs that use undocumented build environment dependencies discover this problem at PCA; the fix is to maintain the build environment as a configuration-controlled container image whose exact content is part of the PBL documentation.

# Build environment specification — PBL artifact
build_environment:
  base_image: rhel9.4-build:2026.06.15
  compiler:   gcc-13.3.1
  linker:     binutils-2.41
  make:       gnu-make-4.4.1
  java:       openjdk-21.0.3
  maven:      apache-maven-3.9.8
  flags:
    CFLAGS:   "-O2 -fstack-protector-strong -D_FORTIFY_SOURCE=2"
    LDFLAGS:  "-Wl,-z,relro,-z,now"

# Baseline label (tagged in version control)
source_baseline:  csci-001-v3.2.1
svd_revision:     D

# Verification hash (SHA-256 of deliverable binary)
deliverable_hash: e3b4c7a1f9d25843...

PCA preparation checklist items: confirm that the version control tag matching the SVD exists and is signed; generate the bill of materials from the CMDB and compare it to the actual package set in the build environment; verify that all approved waivers and deviations are documented and signed; and confirm that the open-item list matches the SVD's known anomalies section. Any discrepancy between the CMDB record and the physical product is an audit finding that must be resolved before the PCA can close.

MIL-STD-973 and DO-178C integration

Programs that produce airborne software must satisfy both MIL-STD-973 (the defense acquisition SCM standard) and DO-178C Section 7 (Software Configuration Management for airborne software certification). The two are complementary but have distinct emphases and deliverables.

Configuration Management Plan vs Software Configuration Management Plan. MIL-STD-973 requires a system-level CMP as a CDRL. DO-178C requires a separate Software Configuration Management Plan (SCMP) as a Software Life Cycle Data item. The SCMP must describe how all Software Life Cycle Data (SLCD) is placed under configuration control, how changes are managed, how baselines are established, and how the problem reporting and change control process works. The SCMP is reviewed by the DER (Designated Engineering Representative) or the certification authority as part of the software planning review. The system-level CMP and the SCMP should be consistent and cross-referential, but they are distinct documents with distinct audiences.

CDRLs for configuration management. A typical defense program's CM-related CDRLs include:

DI-CMAN-80858A — Configuration Management Plan: Master SCM process document
DI-CMAN-81259 — Configuration Status Accounting Report: Periodic CI status summary
DI-CMAN-81000 — Engineering Change Proposal: Per-change deliverable
DI-MCCR-80013A — Software Version Description: Per-release deliverable
DI-CMAN-81121 — Interface Control Document: Per-interface deliverable

Tool qualification for SCM tools. DO-178C and the companion standard DO-330 require that Development Tools — tools whose output becomes part of the airborne software or whose failure could introduce undetected errors — be qualified. A version control system whose labeled baseline feeds the SVD deliverable is a candidate for TD3 qualification under DO-330. Qualification evidence includes Tool Operational Requirements (TOR), a Tool Qualification Plan, test records demonstrating the tool correctly stores and retrieves exact binary content, and a Problem Report process for the tool itself. Programs discover this requirement late, after they have already selected and deployed their version control server, because the DO-178C requirement is often read as applying only to compilers and code generators. Starting the Tool Qualification Plan for the SCM tool at the same time as the SCMP — during software planning — prevents the last-minute qualification scramble that delays certification.

Problem reporting and change control. DO-178C Section 7.3 requires a documented problem reporting process for all software life cycle data under CM control. Every anomaly — not just code defects, but errors in requirements, test procedures, design documents, and analysis reports — must be entered in the problem reporting system and tracked to closure. The problem report data feeds the FCA (showing open anomalies and their disposition) and the PCA (showing that the known anomaly list in the SVD is accurate and complete). Integrating the problem reporting system with the ECP workflow ensures that problems that require a baseline change generate an ECP automatically, rather than living in a separate defect tracker that auditors cannot correlate to the controlled baseline.

Programs that invest in this integration — a requirements tool feeding traceability to a test management tool, which feeds results to a CMDB that links to the ECP workflow — have demonstrably shorter FCA and PCA cycles and fewer post-audit findings than programs that manage these records in disconnected spreadsheets. The investment is significant, but the alternative — reconstructing audit evidence under time pressure as government representatives wait — is more expensive and more damaging to program relationships.

Configuration management for defense software: baselines, CCBs and audit trails