Managementul configurației pentru software-ul de apărare: linii de bază, CCB-uri și trasee de audit

Managementul configurației software în context comercial este în mare parte sinonim cu controlul versiunilor. În programele de apărare, controlul versiunilor reprezintă cea mai mică parte din obligațiile SCM. Disciplina reală cuprinde stabilirea formală a liniilor de bază, un Consiliu de Control al Modificărilor funcțional, propuneri de modificare inginerești documentate, rapoarte de contabilizare a stării configurației și audituri de configurație pe care un reprezentant guvernamental trebuie să le poată verifica. Dacă lipsește oricare dintre aceste elemente, riscați constatări contractuale, întârzieri de calendar la integrarea sistemelor și audituri eșuate care blochează livrările. Acest ghid acoperă fiecare element în ordine — ce înseamnă, cum se implementează corect și unde eșuează de obicei programele.

Ce înseamnă managementul configurației în programele de apărare

Managementul configurației în contextul apărării este o disciplină de management definită de MIL-STD-973 și echivalentele sale civile (EIA-649, ISO 10007). Acoperă patru funcții de bază: identificarea configurației (care sunt elementele controlate și atributele lor?), controlul configurației (cum sunt evaluate și aprobate modificările?), contabilizarea stării configurației (care este starea aprobată curentă a fiecărui element?) și verificarea și auditul configurației (produsul corespunde liniei de bază aprobate?).

Domeniul de aplicare se extinde cu mult dincolo de codul sursă. Elementele de configurație (CI) ale unui sistem de apărare includ ansambluri hardware, plăci de circuite imprimate, imagini de firmware, executabile software, manuale tehnice, proceduri de testare, documente de control al interfețelor și chiar echipamente de suport. Fiecare CI este desemnat formal cu un identificator unic, o disciplină inginerească proprietară și o relație documentată părinte-copil față de arborele CI la nivel de sistem. Modificarea oricărui atribut al unui CI — specificația de performanță, definiția interfeței, numărul de piesă — declanșează procesul de control al configurației.

Pentru echipele de software, implicația practică este că SCM nu aparține exclusiv grupului de software. Provocările agile ale software-ului de apărare care apar din dezvoltarea concurentă a hardware-ului și software-ului sunt fundamental o problemă de management al configurației: atunci când CI-urile hardware își modifică specificațiile de interfață, CI-urile software trebuie notificate și actualizate printr-un proces formal, nu printr-un mesaj informal. Documentul de control al interfeței (ICD) este un element controlat; modificările aduse acestuia necesită o Propunere de Modificare Inginerească aprobată înainte de începerea oricărei implementări.

Această amploare explică de ce programele de apărare mențin un Birou de Management al Configurației (CMO) dedicat, format din specialiști, în loc să atribuie responsabilitățile SCM unui dezvoltator cu normă parțială. CMO menține Baza de date de management al configurației, pregătește și prezidează CCB, urmărește toate ECP-urile deschise și se pregătește pentru auditurile de configurație. În programele cu mai puțin de 50 de persoane, CMO poate fi o singură persoană — dar trebuie să fie o persoană, cu timp dedicat, nu un comitet fără un responsabil clar.

Tipuri de linii de bază și ciclul lor de viață

MIL-STD-973 definește trei tipuri formale de linii de bază care marchează etapele din ciclul de viață al dezvoltării sistemului. Fiecare linie de bază este un instantaneu controlat al documentației tehnice aprobate pentru sistem sau un CI la un moment definit din program.

Linia de bază funcțională. FBL este stabilită atunci când guvernul acceptă specificația funcțională la nivel de sistem la PDR. Surprinde ce trebuie să facă sistemul — cerințe de performanță, funcționale și de interfață — fără a specifica cum. Odată închisă, modificările la FBL necesită un ECP de clasa I și acordul guvernului. Echipele de software descoperă modificările FBL cel mai dureros în timpul auditurilor de configurație funcționale, când pe lista de verificare a auditului apar cerințe despre care nu au fost notificate formal.

Linia de bază alocată. ABL se închide la CDR și controlează modul în care cerințele la nivel de sistem sunt distribuite între CI-uri. Specificația cerințelor software (SRS) a fiecărui CI software urmărește ABL. Dacă o cerință de sistem este ulterior realocată — de exemplu, o cerință de sincronizare se mută de la un CI hardware la un CI software — această realocare este o modificare de clasa I care necesită aprobarea CCB și revizuirea SRS înainte ca echipa software să modifice o singură linie de cod. Programele care permit realocări informale în discuțiile de pe holuri ajung cu un SRS care reflectă implementarea reală în loc de cerințele aprobate, ceea ce eșuează FCA de fiecare dată.

Linia de bază a produsului. PBL este culminarea procesului de dezvoltare, stabilită după ce Auditul configurației fizice confirmă că produsul livrat corespunde configurației documentate. PBL include specificația de construire (versiunea exactă a sursei, compilatorul, lanțul de instrumente și parametrii de construire necesari pentru a reproduce livrabilul), Descrierea versiunii software și lista de materiale ca-atare. Odată stabilit PBL, produsul intră în controlul configurației de susținere — toate modificările, oricât de mici, necesită ECP-uri formale prin CCB.

Structura și operațiunile consiliului de control al modificărilor

CCB este organismul de decizie care evaluează modificările propuse la liniile de bază controlate. Nu este un consiliu de revizuire sau un grup consultativ tehnic — este o autoritate formală cu o cartă documentată, o componență definită și reguli de vot obligatorii. Un CCB care funcționează informal, care ia decizii în fire de e-mail ad-hoc în loc de ședințe formale cu procese-verbale înregistrate, nu este un CCB în sensul MIL-STD-973 și nu va satisface un audit guvernamental.

Carta. Carta CCB este un document controlat (gestionat el însuși sub SCM) care definește: autoritatea și domeniul de aplicare al CCB; componența permanentă și înlocuitorii; cerințele de cvorum (de obicei, majoritatea membrilor cu drept de vot); regulile de vot pentru modificările de rutină, modificările controversate și procedurile de urgență; formatul de depunere a ECP și informațiile justificative necesare; termenele de decizie (de exemplu, ECP-urile de rutină decise în termen de 10 zile lucrătoare de la depunere); și calea de escaladare atunci când CCB nu poate ajunge la o decizie.

Componența pentru un program de dimensiuni medii. Un CCB pentru un program de software de apărare cu 30–100 de persoane include de obicei:

• Președinte: Inginer șef sau manager de program — vot de departajare, asigură respectarea cartei
• Secretar: Ofițer de management al configurației — pregătește agendele, înregistrează procesele-verbale, menține CMDB
• Membri cu drept de vot: Responsabil inginerie sisteme, Responsabil software, Responsabil hardware, Responsabil testare, Reprezentant logistică/ILS
• Participanți fără drept de vot: Inițiatorul ECP, responsabilii subsistemelor afectate, analistul de costuri/calendar
• Reprezentant guvernamental: COTR sau PM — necesar pentru modificările de clasa I, poate participa sau furniza acordul scris

Cadența ședințelor. Majoritatea programelor organizează ședințe săptămânale ale CCB pentru modificările de rutină, cu o agendă permanentă care include: starea ECP-urilor aprobate anterior; ECP-urile noi depuse de la ultima ședință (revizuire inițială succintă); prezentări complete și voturi pentru ECP-urile pregătite pentru decizie; și ratificările modificărilor de urgență. Modificările de urgență sunt autorizate în afara benzii de către președintele CCB (și reprezentantul guvernamental pentru clasa I) și ratificate la următoarea ședință programată a CCB — înregistrarea ratificării închide autorizarea de urgență.

Procese-verbale și înregistrări. Procesele-verbale de proiect trebuie distribuite în termen de 48 de ore de la ședință și finalizate în termen de cinci zile lucrătoare. Procesele-verbale înregistrează: participanții, starea cvorumului, ECP-urile revizuite cu decizia și numărul de voturi, elementele de acțiune cu responsabilii și termenele limită și orice opinii divergente privind deciziile controversate. Procesele-verbale sunt documente controlate arhivate în CMDB. Consecvența secretarului CM în producerea și arhivarea proceselor-verbale este unul dintre cei mai importanți factori care determină cât de pregătit este un program pentru un audit de configurație.

Propuneri de modificare inginerești: clasa I față de clasa II

O Propunere de Modificare Inginerească (ECP) este vehiculul formal pentru propunerea, evaluarea și aprobarea modificărilor la o linie de bază controlată. Orice modificare la un element controlat de configurație care ar afecta FBL, ABL sau PBL trebuie documentată într-un ECP înainte de începerea implementării — nu după.

Clasa I față de clasa II. Distincția determină cine aprobă modificarea și cât de mult proces necesită:

• Clasa I: Afectează o linie de bază controlată formal, un angajament contractual, o interfață aprobată (ICD), o cerință critică de siguranță sau forma/potrivirea/funcția unui livrabil. Necesită aprobarea CCB plus acordul guvernului. Implementarea este blocată până la obținerea aprobării. Exemple tipice: adăugarea unei noi capacități în SRS, modificarea unui câmp de date ICD, modificarea unei cerințe de siguranță, ștergerea unei proceduri de testare din planul de testare aprobat.
• Clasa II: Modificare tehnică internă care nu afectează nicio linie de bază controlată, livrabil contractual sau interfață aprobată. Aprobată de CCB intern al contractantului fără implicarea achizitorului. Înregistrată pentru traseul de audit, dar nu supusă revizuirii guvernamentale. Exemple tipice: refactorizarea structurii modulelor interne, modificarea unei structuri de date non-interfață, actualizarea standardelor interne de codare într-un ghid de stil care nu este un CDRL.

Limita dintre clasa I și clasa II este o sursă frecventă de dezacord. CMP trebuie să definească această limită cu exemple detaliate. O capcană frecventă este aceea că inginerii decid în mod independent că modificarea lor este de clasa II când este de fapt de clasa I — modificarea formatului intern al datelor unui mesaj care traversează o limită de CI este o modificare de clasa I chiar dacă interfața externă (ICD) pare neschimbată, deoarece formatul mesajului este o interfață implicită.

Evaluarea impactului. Fiecare ECP necesită o evaluare structurată a impactului înainte de a putea fi supus la vot. Evaluarea acoperă: riscul tehnic (ce poate merge greșit cu modificarea propusă?); impactul asupra calendarului (câte zile adaugă la calendar, inclusiv regresia de testare?); impactul asupra costurilor (care este costul estimat al forței de muncă și al materialelor?); impactul asupra siguranței (afectează această modificare vreo funcție critică de siguranță sau ipoteză din studiul de caz de siguranță?); și impactul asupra interfeței (care alte CI-uri, dacă există, trebuie să facă modificări corespunzătoare?). Pentru modificările de clasa I, evaluarea impactului este pregătită în comun de inginerul inițiator, analistul de costuri/calendar și inginerul de sisteme. Pentru modificările cu impact asupra siguranței, inginerul de siguranță revizuiește și semnează evaluarea înainte de depunerea la CCB.

Ciclul de viață al ECP: inițiatorul redactează ECP → secretarul CM atribuie numărul și îl înregistrează în CMDB → CCB revizuiește în ședință → CCB votează (aprobare / respingere / amânare) → se obține acordul guvernului pentru clasa I → starea ECP actualizată la „Aprobat pentru implementare" în CMDB → inginerul implementează modificarea → commit-ul în controlul versiunilor este etichetat cu numărul ECP → dovezile de testare sunt legate de ECP în CMDB → ECP-ul este închis. Acest traseu de audit complet — de la inițiere prin implementare și dovezi de testare — este ceea ce caută auditorii guvernamentali în timpul FCA și PCA. Consultați și ghidul nostru despre aplicarea SBOM în conductele de apărare, care intersectează managementul ECP pentru modificările lanțului de aprovizionare software.

Lanțul de instrumente pentru managementul configurației software

Lanțul de instrumente SCM pentru un program de apărare trebuie să satisfacă trei constrângeri care nu se aplică în dezvoltarea comercială: instrumentele trebuie să fie aprobabile în baza Autorității de operare (ATO) a programului; trebuie să suporte trasabilitatea formală cerută de MIL-STD-973 și orice standard de navigabilitate aplicabil; și — pentru majoritatea programelor de apărare — trebuie să funcționeze într-un mediu de rețea izolat sau parțial izolat (air-gapped).

Controlul versiunilor. Git este standardul de facto în programele de apărare neclasificate și clasificate. Pentru programele clasificate, serverele Git auto-găzduite (GitLab Self-Managed, Bitbucket Data Center sau Gitea) sunt desfășurate în interiorul enclavei acreditate. Regulile de protecție a ramurilor impun cerințele de revizuire; commit-urile semnate oferă non-repudiere pentru traseul de audit. Convențiile de denumire a depozitelor și ramurilor trebuie documentate în CMP și aplicate prin cârlige pe server. Pentru programele cu obligații DO-178C, sistemul de control al versiunilor este un candidat pentru calificarea instrumentului — TQP trebuie să acopere versiunea specifică a serverului, configurația și operațiunea de etichetare a liniei de bază care alimentează Descrierea versiunii software. Pentru contextul mai larg al rulării CI/CD în aceste medii, consultați articolul nostru despre CI/CD pentru apărarea air-gapped.

Managementul cerințelor. IBM Engineering Requirements Management DOORS (Classic și Next Generation) rămâne cel mai utilizat instrument de cerințe în programele de apărare, în special cele guvernate de MIL-STD-973 și DO-178C. Jama Software și PTC Windchill Requirements sunt alternative frecvente. Instrumentul de cerințe trebuie să suporte trasabilitatea bidirecțională (cerință → caz de testare → rezultat al testului) și trebuie să genereze artefactele matricei de trasabilitate cerute de SDP/SCMP ca CDRL-uri. Instrumentul trebuie operat sub control de configurație: baza de date de cerințe este un element de configurație, modificările cerințelor în instrument sunt controlate, iar ieșirea instrumentului trebuie să fie reproductibilă dintr-o linie de bază etichetată.

Baza de date de management al configurației. CMDB urmărește starea CI, asocierile de linii de bază, înregistrările ECP, înregistrările de renunțare/deviere și datele de contabilizare a stării configurației. În programele mari, CMDB este adesea IBM Engineering Lifecycle Management (ELM) sau o instanță Jira configurată cu un plugin CM. Programele mai mici folosesc uneori o combinație disciplinată Confluence + Jira. Indiferent de alegere, CMDB trebuie să fie în limita acreditată, să aibă controale de acces care să împiedice modificarea neautorizată a înregistrărilor aprobate și să genereze raportul periodic de contabilizare a stării configurației care este un CDRL în majoritatea programelor.

Configurarea serverului SCM air-gapped. Serverul Git auto-găzduit și CMDB sunt desfășurate pe instanțe RHEL întărite STIG în interiorul enclavei clasificate. Nicio conexiune la serviciile publice de găzduire a depozitelor. Actualizările de pachete pentru software-ul serverului urmează procedura de transfer de suporturi a programului. Certificatele TLS ale serverului sunt emise de PKI intern al programului. Copiile de rezervă sunt stocate în enclavă folosind stocare criptată cu proceduri de recuperare documentate. Accesul la serverul de control al versiunilor este guvernat de lista de control al accesului a programului, cu permisiuni bazate pe rol care separă accesul la citire, scriere și administrare.

Audituri de configurație: FCA și PCA

Auditurile de configurație sunt revizuiri formale efectuate de sau cu participarea guvernului pentru a verifica că un CI sau sistem îndeplinește cerințele specificate (FCA) și că produsul este documentat cu acuratețe (PCA). Nu sunt puncte de control opționale — sunt etape contractuale care condiționează livrările și plățile.

Auditul de configurație funcțională (FCA). FCA verifică că CI-ul software a satisfăcut toate cerințele alocate. Echipa de audit guvernamentală revizuiește: SRS-ul aprobat (documentul ABL) care prezintă fiecare cerință; procedurile de testare care testează fiecare cerință; rezultatele testelor care arată execuția cu succes; matricea de trasabilitate care leagă cerințele de teste la rezultate; și rapoartele de discrepanțe deschise care arată toate anomaliile cunoscute și starea rezolvării acestora. O constatare frecventă de audit este cerințele fără niciun test asociat — „cerințe orfane" pe care echipele de inginerie intenționau să le testeze dar nu le-au acoperit formal. La fel de frecventă este procedurile de testare care pretind că satisfac o cerință dar testează de fapt ceva adiacent — auditorii citesc procedurile de testare în raport cu textul cerințelor la propriu. Pregătirea FCA necesită generarea matricei de trasabilitate din instrumentul de cerințe cu 60+ de zile înainte, revizuirea acesteia pentru lacune și închiderea sau documentarea acelor lacune înainte de audit.

Auditul de configurație fizică (PCA). PCA verifică că produsul care urmează să fie livrat sau desfășurat corespunde exact configurației documentate. Demonstrația de bază este reproductibilitatea construirii: contractantul trebuie să arate că, pornind de la linia de bază a sursei controlate identificată în Descrierea versiunii software, poate reproduce un binar care este identic octet-cu-octet cu livrabilul. Aceasta necesită o specificație completă a mediului de construire — nu doar versiunea compilatorului, ci fiecare instrument din lanțul de construire, fiecare indicator de construire, fiecare variabilă de mediu care influențează ieșirea. Programele care utilizează dependențe nedocumentate ale mediului de construire descoperă această problemă la PCA; soluția este menținerea mediului de construire ca imagine de container controlată de configurație al cărei conținut exact face parte din documentația PBL.

# 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...  
            

Elementele listei de verificare pentru pregătirea PCA: confirmați că eticheta de control al versiunilor care corespunde SVD există și este semnată; generați lista de materiale din CMDB și comparați-o cu setul real de pachete din mediul de construire; verificați că toate renunțările și devierile aprobate sunt documentate și semnate; și confirmați că lista de elemente deschise corespunde secțiunii de anomalii cunoscute din SVD. Orice discrepanță între înregistrarea CMDB și produsul fizic este o constatare de audit care trebuie rezolvată înainte ca PCA să poată fi închis.

Integrarea MIL-STD-973 și DO-178C

Programele care produc software aeronautic trebuie să satisfacă atât MIL-STD-973 (standardul SCM de achiziție apărare) cât și DO-178C Secțiunea 7 (Managementul configurației software pentru certificarea software-ului aeronautic). Cele două sunt complementare, dar au accente și livrabile distincte.

Planul de management al configurației față de Planul de management al configurației software. MIL-STD-973 necesită un CMP la nivel de sistem ca CDRL. DO-178C necesită un Plan de management al configurației software (SCMP) separat ca element de date din ciclul de viață al software-ului. SCMP trebuie să descrie cum sunt plasate sub control de configurație toate datele din ciclul de viață al software-ului (SLCD), cum sunt gestionate modificările, cum sunt stabilite liniile de bază și cum funcționează procesul de raportare a problemelor și control al modificărilor. SCMP este revizuit de DER (Reprezentantul ingineriei desemnate) sau autoritatea de certificare ca parte a revizuirii planificării software. CMP la nivel de sistem și SCMP trebuie să fie consecvente și cu referințe încrucișate, dar sunt documente distincte cu audiențe distincte.

CDRL-uri pentru managementul configurației. CDRL-urile legate de CM ale unui program tipic de apărare includ:

• DI-CMAN-80858A — Planul de management al configurației: Document principal al procesului SCM
• DI-CMAN-81259 — Raportul de contabilizare a stării configurației: Rezumatul periodic al stării CI
• DI-CMAN-81000 — Propunere de modificare inginerească: Livrabil per modificare
• DI-MCCR-80013A — Descrierea versiunii software: Livrabil per versiune
• DI-CMAN-81121 — Document de control al interfeței: Livrabil per interfață

Calificarea instrumentelor pentru instrumentele SCM. DO-178C și standardul companion DO-330 cer ca instrumentele de dezvoltare — instrumente ale căror ieșiri devin parte din software-ul aeronautic sau al căror eșec ar putea introduce erori nedetectate — să fie calificate. Un sistem de control al versiunilor a cărui linie de bază etichetată alimentează livrabilul SVD este un candidat pentru calificarea TD3 sub DO-330. Dovezile de calificare includ Cerințele operaționale ale instrumentului (TOR), un Plan de calificare a instrumentului, înregistrări de testare care demonstrează că instrumentul stochează și recuperează corect conținutul binar exact și un proces de raportare a problemelor pentru instrumentul însuși. Programele descoperă această cerință târziu, după ce au selectat și desfășurat deja serverul lor de control al versiunilor, deoarece cerința DO-178C este adesea citită ca aplicându-se doar compilatoarelor și generatoarelor de cod. Începerea Planului de calificare a instrumentului pentru instrumentul SCM în același timp cu SCMP — în timpul planificării software — previne scramble-ul de calificare de ultim moment care întârzie certificarea.

Raportarea problemelor și controlul modificărilor. DO-178C Secțiunea 7.3 necesită un proces documentat de raportare a problemelor pentru toate datele din ciclul de viață al software-ului aflate sub control CM. Fiecare anomalie — nu doar defectele de cod, ci și erorile din cerințe, proceduri de testare, documente de proiectare și rapoarte de analiză — trebuie introdusă în sistemul de raportare a problemelor și urmărită până la rezolvare. Datele rapoartelor de probleme alimentează FCA (arătând anomaliile deschise și dispoziția lor) și PCA (arătând că lista de anomalii cunoscute din SVD este exactă și completă). Integrarea sistemului de raportare a problemelor cu fluxul de lucru ECP asigură că problemele care necesită o modificare a liniei de bază generează automat un ECP, în loc să trăiască într-un sistem de urmărire a defectelor separat pe care auditorii nu îl pot corela cu linia de bază controlată.

Programele care investesc în această integrare — un instrument de cerințe care alimentează trasabilitatea unui instrument de management al testelor, care alimentează rezultatele unui CMDB legat de fluxul de lucru ECP — au cicluri FCA și PCA demonstrabil mai scurte și mai puține constatări post-audit decât programele care gestionează aceste înregistrări în foi de calcul deconectate. Investiția este semnificativă, dar alternativa — reconstruirea dovezilor de audit sub presiunea timpului în timp ce reprezentanții guvernamentali așteaptă — este mai costisitoare și mai dăunătoare relațiilor din cadrul programului.