서론
소프트웨어는 위성, 지상 네트워크, 운영사, 고객 및 규제기관 사이에 위치합니다. 임무 통제 시스템은 교신 일정을 계획하고, 명령을 검증 및 전송하며, 원격측정을 수신 및 처리하고, 우주선 상태를 모니터링하며, 궤도를 계산하고, 탑재체 일정을 관리하며, 운영 기록을 보존합니다. 결함, 이용 불가한 의존성 또는 접근 불가능한 서명 키는 기반 우주선이 기술적으로 정상이더라도 수익을 중단시키고 명령 권한을 약화시킬 수 있습니다.
따라서 인수에는 통상적인 소프트웨어 제품 검토 이상의 것이 포함됩니다. 인수자는 실제 운영되는 임무 시스템을 이해해야 합니다. 해당 시스템에는 소스 저장소, 빌드 파이프라인, 구성 데이터, 배포 환경, 암호화 자료, 지상 인터페이스, 런북, 공급업체 서비스, 엔지니어링 판단 및 계약상 권리가 포함됩니다. 이러한 요소 중 일부는 대상 법인 외부에 있거나 특정 개인에게 의존할 수 있습니다.
본 백서는 그 문제에 대한 거래 프레임워크를 제시합니다. 이는 소프트웨어 주도 우주 거래를 평가하는 전략적 인수자, 인프라 투자자, 프라이빗 캐피털 운용사, 위성 운영사, 대출기관 및 이사회를 위해 설계되었습니다. 통제, 연속성, 가격, 조건 및 통합 설계를 바꾸는 증거에 초점을 둡니다.
1 인수 대상 역량 정의
인수자는 역량 명세서로 시작해야 합니다. 이 명세서는 소프트웨어가 어떤 임무, 우주선, 탑재체, 지상 사이트, 고객 서비스 및 운영 의사결정을 지원하는지 식별합니다. 서비스 시간대, 가용성 기대치, 안전 결과, 규제 의무 및 수익 의존성을 기록합니다. 제품명만으로는 신뢰할 수 있는 범위를 정하기 어렵습니다. 하나의 브랜드 플랫폼이 별도의 비행역학, 계획, 아이덴티티, 데이터베이스, 모니터링 및 지상국 서비스에 의존할 수 있기 때문입니다.
역량 명세서는 비행 소프트웨어와 지상 소프트웨어를 구분해야 합니다. 위성 통제 인수는 보통 지상 부문에 초점을 두지만, 운영 가치는 내장 비행 인터페이스 및 우주선별 명령 데이터베이스에 의존할 수 있습니다. 인수자는 대상이 계속 운영에 필요한 모든 인터페이스를 사용, 수정 및 이전할 수 있다는 증거를 필요로 합니다.
범위에는 제외 서비스도 식별해야 합니다. 공유 기업 아이덴티티, 클라우드 구독, 통신 링크, 키 관리 서비스, 데이터 센터 또는 모회사 직원은 첫날부터 필수일 수 있습니다. 각 제외 항목은 전환 요건, 지속 의존성 또는 가치 조정이 됩니다.
2 소유권, 접근권 및 통제권의 분리
법적 소유권은 통제의 한 요소입니다. 인수자는 또한 물리적 또는 논리적 접근, 수정 및 배포할 충분한 권리, 운영 지식, 자격증명 및 릴리스 결정에 대한 권한을 필요로 합니다. 이러한 요소는 서로 어긋날 수 있습니다. 대상은 맞춤형 소스 코드를 소유하면서도 양도 불가능한 라이브러리에 의존할 수 있습니다. 저장소를 보유하면서도 프로덕션 빌드가 컨설턴트의 사설 툴체인에 의존할 수 있습니다. 광범위한 라이선스를 보유하면서도 정부 고객이 배포 승인을 통제할 수 있습니다.
실사 모델은 소유권, 점유, 접근, 수정 권리, 배포 권리, 운영 권한 및 종료 권리를 별도로 기록해야 합니다. 각 항목에는 문서 증거가 필요합니다. 관련 증거에는 권리 양도 문서, 고용 조건, 계약자 계약, 라이선스 일람, 저장소 권한, 배포 기록, 고객 계약 및 공급업체 확인서가 포함됩니다.
통제에는 시간적 차원도 있습니다. 실사 중 존재하는 접근권은 클로징 시 만료될 수 있습니다. 인수자는 거래 경계를 넘어 저장소 접근, 클라우드 테넌시, 서명 권한, 관리자 자격증명, 모니터링 이력 및 공급업체 지원을 유지하는 데 필요한 정확한 조치를 식별해야 합니다.
3 소프트웨어 및 의존성 인벤토리 구축
인벤토리는 애플리케이션, 서비스, 저장소, 브랜치, 빌드 시스템, 배포 패키지, 데이터베이스, 인터페이스, 상용 제품, 오픈소스 구성요소, 암호화 라이브러리 및 운영 스크립트를 식별해야 합니다. 각 구성요소를 그것이 지원하는 임무 기능 및 실행 환경과 연결해야 합니다.
SBOM은 구성요소 발견을 가속할 수 있습니다. 그러나 운영 인벤토리를 대체하지는 않습니다. 유용한 인수 인벤토리는 구성요소 이름 및 버전을 소스, 라이선스, 유지관리자, 취약점 상태, 빌드 산출물, 배포된 구성, 데이터 의존성 및 교체 경로와 연결합니다. 컨테이너, 펌웨어 또는 공급업체 어플라이언스에 내장된 구성요소는 통상적인 애플리케이션 목록에서 빠질 수 있으므로 주의가 필요합니다.
인수자는 세 가지 관점을 조정해야 합니다. 엔지니어링이 존재한다고 말하는 것, 저장소가 포함하는 것, 그리고 프로덕션 원격측정이 실행 중이라고 보여주는 것입니다. 차이는 실사 발견사항입니다. 기록되지 않은 서비스가 중요할 수 있습니다. 목록에 있는 저장소가 폐기되었을 수 있습니다. 프로덕션 바이너리가 승인된 소스 커밋으로 추적되지 않을 수 있습니다.
4 소스 코드 완전성 테스트
저장소 접근은 전체 제품과 그 이력을 포괄해야 합니다. 매수자는 소스, 구성, 인프라 정의, 데이터베이스 스키마, 테스트 자산, 빌드 스크립트, 배포 자동화, 문서 및 이슈 이력을 검사해야 합니다. 선별된 파일의 스냅샷만으로는 완전성을 입증할 수 없습니다.
완전성 테스트는 배포된 산출물에서 시작합니다. 팀은 대표적인 운영 바이너리 또는 컨테이너를 식별하고 이를 소스 리비전, 종속성 버전, 빌드 매개변수 및 승인 기록까지 역추적합니다. 그런 다음 통제된 환경에서 소프트웨어를 빌드하고 그 결과를 배포된 산출물 또는 문서화된 출처와 비교합니다. 차이가 있으면 설명이 필요합니다.
생성된 코드는 별도로 다루어야 합니다. NASA 지침은 장기 유지보수 시 모델, 시뮬레이션, 데이터 정의, 생성기, 빌드 데이터, 테스트 스크립트 및 예상 결과에 대한 접근이 필요할 수 있음을 인정합니다. 생성기, 모델 또는 검증된 구성이 누락된 경우 생성된 소스의 보유만으로는 충분하지 않을 수 있습니다.
5 빌드 재현
재현 가능한 빌드는 가치가 높은 실사 테스트입니다. 목적은 권한을 부여받은 팀이 문서화되지 않은 개입 없이 통제된 입력으로 배포 가능한 릴리스를 생성할 수 있음을 입증하는 것입니다. 테스트는 깨끗한 환경과 대상의 문서화된 절차를 사용해야 합니다. 매수자 측 관찰자는 전제 조건, 외부 다운로드, 자격 증명, 수동 단계, 도구 버전, 경고 및 편차를 기록해야 합니다.
기존 프로세스가 결정론적 컴파일을 지원하지 않는 경우 결과가 비트 단위로 동일할 필요는 없습니다. 합의된 테스트에서 추적 가능하고 기능적으로 동등해야 합니다. 매수자는 차이가 발생하는 이유와 프로세스가 무결성을 유지하는지 이해해야 합니다.
빌드 실패는 누락된 라이선스, 만료된 인증서, 사용할 수 없는 패키지 저장소, 문서화되지 않은 패치 또는 특정 엔지니어에 대한 의존성을 드러낼 수 있습니다. 이러한 발견은 전환 비용 및 연속성 위험과 직접 연결됩니다. 구매 계약은 종결 전에 성공적인 클린 빌드를 요구하거나 조건이 충족될 때까지 대금을 에스크로에 둘 수 있습니다.
6 릴리스 및 배포 권한 추적
소스 접근은 운영 환경을 운영할 수 있는 능력을 입증하지 않습니다. 매수자는 코드 승인부터 빌드, 서명, 릴리스, 배포 및 롤백에 이르는 권한을 추적해야 합니다. 이 추적은 변경을 승인할 수 있는 사람, 서명 자격 증명을 보유한 사람, 패키지가 저장되는 위치, 환경이 승격되는 방식 및 긴급 릴리스가 통제되는 방식을 식별합니다.
위성 제어 변경은 임무 안전에 중대한 결과를 초래할 수 있습니다. 릴리스 증거에는 검증 결과, 운영 준비 검토, 구성 승인, 해당되는 경우 고객 또는 당국의 동의, 테스트된 복구 경로가 포함되어야 합니다. 매수자는 일상적인 애플리케이션 릴리스와 명령 검증, 비행 역학, 텔레메트리 해석 또는 암호화 신뢰 변경을 구분해야 합니다.
자격 증명 이전에는 설계된 프로세스가 필요합니다. 개인 키와 특권 자격 증명은 종결 과정에서 무심코 복사해서는 안 됩니다. 당사자들은 교체, 폐기, 재등록, 이중 통제, 감사 보존 및 롤백에 합의해야 합니다. 종결 계획은 운영 권한이 언제 변경되는지와 모호한 책임을 어떻게 회피하는지를 명시해야 합니다.
7 임무 구성 데이터 검토
임무 통제 소프트웨어는 소스 코드만큼 가치가 있을 수 있는 구성에 의존합니다. 명령 사전, 텔레메트리 정의, 한계값, 보정 데이터, 우주선 모델, 교신 계획, 궤도 매개변수, 자동화 규칙 및 고객 라우팅은 일반 소프트웨어가 실제 위성군과 상호작용하는 방식을 결정합니다.
매수자는 각 구성 클래스의 권위 있는 출처, 승인 프로세스, 버전 이력 및 복구 방법을 식별해야 합니다. 통제된 기록으로 새 환경을 채울 수 있는지 테스트해야 합니다. 스프레드시트 기반 또는 로컬에 저장된 구성은 검토, 출처 이력 및 백업이 없을 때 위험을 초래합니다.
구성 권리도 중요합니다. 고객, 우주선 제조사 또는 시스템 통합업체가 데이터의 일부를 소유하거나 제한할 수 있습니다. 인수 계약은 이전, 계속 사용, 기밀성, 수출 제한 및 삭제 의무를 다루어야 합니다. 구성이 누락되면 다른 측면에서 완전한 소프트웨어라도 특정 임무에는 사용할 수 없게 될 수 있습니다.
8 소프트웨어 보증 증거 평가
소프트웨어 보증 증거는 제품이 통제된 관행을 통해 개발·유지되었는지 보여줍니다. NIST의 SSDF는 조직 준비, 소프트웨어 보호, 안전하게 보호된 소프트웨어 생산, 취약점 대응을 중심으로 보안 개발을 구성합니다. NASA의 소프트웨어 보증 지침은 안전 및 임무 맥락에 대한 객관적 증거를 추가합니다.
구매자는 요구사항 추적성, 아키텍처 결정, 코드 리뷰, 정적 분석, 의존성 스캔, 테스트 커버리지, 릴리스 승인, 결함 이력 및 취약점 대응을 검토해야 합니다. 증거는 운영 환경의 버전과 일치해야 합니다. 실행 기록이 없는 정책 문서는 제한적인 보증만 제공합니다.
실사 팀은 명령 생성, 인증, 권한 관리, 궤도 결정 및 복구와 같은 핵심 경로를 표본 검사해야 합니다. 테스트가 불리한 조건 및 경계 조건을 포괄하는지 검토해야 합니다. 미해결 발견 사항은 임무 영향, 악용 가능성, 복구 가능성 및 교정 의존성에 따라 분류해야 합니다.
9 소프트웨어 공급망 매핑
공급망에는 상용 공급업체, 오픈소스 프로젝트, 클라우드 제공업체, 빌드 서비스, 패키지 저장소, 하드웨어 공급업체, 컨설턴트 및 전문 운영업체가 포함됩니다. 구매자는 어떤 당사자가 제품을 변경, 중단, 접근 또는 제약할 수 있는지 매핑해야 합니다.
각 핵심 공급업체에 대해 실사는 계약상 지원, 재무적 회복력, 보안 관행, 접근 권한, 사고 통지, 변경 통제, 수명 종료 정책, 데이터 위치 및 대체 리드 타임을 다루어야 합니다. 여러 임무 핵심 구성요소를 지원하는 공급업체는 연간 지출이 적더라도 집중 위험을 초래합니다.
NIST SP 800-161 은 공급망 위험을 조달 체크리스트가 아니라 조직 거버넌스 문제로 취급합니다. 거래 팀은 공급업체 증거를 시스템 중요도 및 계획된 소유권과 연결해야 합니다. 중요 공급업체는 종결 전 동의, 노베이션 또는 직접 계약이 필요할 수 있습니다.
10 오픈소스 익스포저 분석
오픈소스 구성요소는 기능을 개선하고 개발 시간을 단축할 수 있습니다. 또한 라이선스, 유지보수 및 보안 의무를 발생시킵니다. 구매자는 신고된 구성요소를 코드 스캔 및 빌드 매니페스트와 대조해야 합니다. 라이선스 조건, 수정 사항, 고지, 배포 관행 및 알려진 취약점을 식별해야 합니다.
카피레프트 익스포저는 실제 사용 및 배포 방식을 기준으로 법률 분석이 필요합니다. 라이선스 표시만으로는 의무가 성립하지 않습니다. 팀은 구성요소가 어떻게 연결, 배포, 수정 및 고객 제공되는지 문서화해야 합니다. 교정 조치에는 고지 수정, 소스 제공, 구성요소 교체 또는 고객 커뮤니케이션이 포함될 수 있습니다.
유지보수 상태는 가치에 영향을 미칩니다. 활성 유지관리자나 지원되는 릴리스가 없는 핵심 라이브러리는 내부에서 직접 소유·관리해야 할 수 있습니다. 구매자는 포크 전략, 테스트 커버리지, 패치 역량 및 커뮤니티 의존도를 평가해야 합니다. 소프트웨어 자재 명세서(SBOM)는 정적인 실사 산출물로 남지 않고 종결 후에도 최신 상태를 유지해야 합니다.
11 지식재산권 출처 검토
모든 중요 코드 기여에는 입증 가능한 출처 경로가 있어야 합니다. 직원 발명은 적절한 고용 조건의 범위에 포함되어야 합니다. 도급업체 작업은 충분한 범위로 양도되어야 합니다. 취득되거나 기여된 코드에는 필요한 권리가 부여되어야 합니다. 대학, 정부 또는 고객 자금 지원 개발에는 상세 검토가 필요한 제한이 포함될 수 있습니다.
팀은 커밋 이력을 기여자 기록 및 계약과 대조하여 표본 검토해야 합니다. 인식되지 않는 작성자, 개인 계정 또는 설명되지 않는 대량 가져오기는 조사할 가치가 있습니다. 검토에는 문서, 모델, 테스트 데이터, 사용자 인터페이스 및 알고리즘이 포함되어야 합니다. 가치 있는 지식재산은 소스 파일을 넘어 확장되기 때문입니다.
특허 및 영업비밀 분석은 실제 제품과 상업 계획에 초점을 맞춰야 합니다. 매수자는 방어적 등록, 자유 실시(FTO) 검토, 기밀 통제 및 영업비밀 보호를 약화시킬 수 있는 모든 공개를 이해해야 합니다. 거래 문서는 보증, 배상, 에스크로 또는 조건부 대가를 통해 특정 출처 리스크를 배분할 수 있습니다.
12 특권 접근 및 분리 테스트
임무 통제 환경은 강력한 권한을 집중시킵니다. 관리자는 명령, ID, 데이터베이스, 클라우드 리소스, 서명 키 및 모니터링을 통제할 수 있습니다. 매수자는 개발, 테스트, 운영 및 복구 환경 전반에 걸쳐 사람, 서비스 및 비상 계정을 포괄하는 권한 인벤토리를 확보해야 합니다.
검토는 입사자, 이동자 및 퇴사자 통제; 다중 요소 인증; 승인; 세션 로깅; 자격 증명 교체; 긴급 접근; 개발과 운영 간 분리를 테스트해야 합니다. 공유 또는 휴면 계정은 책임 소재를 약화시킵니다. 서비스 계정에는 소유권 및 수명주기 통제가 필요합니다.
거래 종결은 접근 리스크를 높입니다. 퇴사 인력은 자격 증명이나 복구 경로에 대한 지식을 보유할 수 있습니다. 전환 계획은 민감한 자격 증명을 교체하고, 이전 접근 권한을 취소하며, 증거를 보존하고, 이중 운영 대응 체계를 유지해야 합니다. 이러한 조치는 접근 상실이 실제 임무에 영향을 미칠 수 있는 경우 연습되어야 합니다.
13 취약점 관리 검토
매수자는 취약점이 어떻게 발견, 분류, 조치 및 전달되는지 이해해야 합니다. 소스에는 정적 분석, 의존성 스캔, 침투 테스트, 고객 보고서, 공급업체 권고 및 운영 모니터링이 포함됩니다. 프로그램은 심각도, 임무 영향, 조치 시점, 예외 승인 및 재테스트를 정의해야 합니다.
백로그 분석은 숨겨진 유지보수 요구사항을 드러낼 수 있습니다. 매수자는 경과 기간, 재발, 영향을 받은 버전 및 종결 품질을 검토해야 합니다. 낮은 건수는 약한 탐지를 반영할 수 있습니다. 높은 건수는 활발한 발견을 반영할 수 있습니다. 유용한 지표는 조직이 관련 노출을 식별하고 리스크 기반 기간 내에 이를 줄일 수 있는 능력입니다.
비행 및 지상 시스템은 패치 적용 기간이 제한적일 수 있습니다. 대상 기업은 보완 통제를 어떻게 적용하고 안전한 릴리스를 계획하는지 보여주어야 합니다. 접근 불가능하거나 수명 종료된 구성요소의 알려진 취약점은 특정 가격 인하 또는 재원이 확보된 조치 충당금을 정당화할 수 있습니다.
14 인터페이스 및 상호운용성 평가
위성 통제 소프트웨어는 우주선, 지상국, 네트워크, ID 시스템, 고객 플랫폼, 기상 데이터, 궤도 데이터 및 규제 서비스와의 인터페이스에 의존합니다. 매수자는 각 인터페이스의 프로토콜, 버전, 소유자, 성능 요구사항, 보안 통제, 테스트 환경 및 변경 프로세스를 목록화해야 합니다.
인터페이스 문서는 관측된 트래픽 및 현재 구성과 대조하여 테스트해야 합니다. 독점 또는 문서화되지 않은 인터페이스는 종속(락인)을 초래합니다. 표준 프로토콜이라도 교체를 복잡하게 만드는 고객별 확장을 포함할 수 있습니다.
팀은 장애 모드를 테스트해야 합니다. 지연 데이터, 중복 메시지, 시계 오류, 손상된 입력, 네트워크 중단 및 부분 서비스 손실을 관찰해야 합니다. 복구 동작은 운영 가치에 영향을 미칩니다. 통합 계획은 인터페이스 관찰 가능성을 유지하고 여러 핵심 의존성을 한 번에 변경하지 않아야 합니다.
15 데이터 권리 및 기록 평가
운영 데이터는 모니터링, 이상 징후 분석, 모델 개선, 고객 보고 및 규제 증거를 지원합니다. 매수자는 텔레메트리, 명령, 파생 제품, 로그, 고객 정보 및 학습 데이터에 대한 소유권, 보관권, 허용 사용권, 보존 및 수출 권한을 구분해야 합니다.
거래 범위에는 시스템 운영 및 개선에 필요한 이력 데이터가 포함되어야 합니다. 매수자는 경보를 조정하거나 이상 징후를 조사하기에 충분한 운영 이력 없이 소프트웨어를 제공받을 수 있습니다. 데이터 이전 시 타임스탬프, 출처, 접근 통제 및 증거 무결성을 보존해야 합니다.
개인정보 및 현지화 의무는 인사 데이터와 고객 데이터에 적용될 수 있습니다. 수출 통제 및 국가 안보 제한은 기술 데이터와 외국인의 접근에 영향을 미칠 수 있습니다. 법률 분석은 의무를 실제 데이터셋과 운영 위치에 매핑해야 합니다.
16 운영 복원력 및 복구 검토
복원력 테스트는 인프라, 소프트웨어, 공급업체 및 인적 장애를 거치면서 서비스가 어떻게 지속되는지를 보여주어야 합니다. 매수자는 이중화, 백업, 복구 환경, 대체 통신 수단, 수동 절차, 복구 목표 및 모의훈련 결과를 검토해야 합니다.
백업은 해당 미션의 허용 범위 내에서 복원될 수 있을 때에만 유용합니다. 실사 팀은 대표적인 복원을 직접 확인하고 구성, 자격 증명, 종속성 및 데이터 무결성을 검증해야 합니다. 복구에는 기본 환경이나 공급업체를 사용할 수 없을 때 시스템을 재구축할 수 있는 능력이 포함되어야 합니다.
인수 자체도 복원력 이벤트로 취급해야 합니다. 기업 시스템, 도메인, 클라우드 계정 및 지원 계약이 변경될 수 있습니다. 상세한 컷오버 계획, 롤백 기준, 지휘 권한 및 공동 사고 프로세스는 전환 위험을 줄여 줍니다.
17 인력 및 지식 집중도 평가
소프트웨어 연속성은 아키텍처, 미션, 이상 징후, 고객 및 운영 판단을 이해하는 인력에 달려 있습니다. 매수자는 역할을 핵심 프로세스에 매핑하고 단일 지식 의존 지점을 식별해야 합니다. 조직도는 제한적인 증거만 제공하므로, 매핑은 실제로 누가 사고를 해결하고 릴리스를 승인하는지를 반영해야 합니다.
잔류 결정은 기술적 중요성과 독립성 모두를 고려해야 합니다. 집중된 지식은 짝 작업, 문서화, 리허설 및 승계를 통해 줄일 수 있습니다. 지식 이전 마일스톤이 없는 잔류 보상은 의존성을 줄이기보다는 유지할 수 있습니다.
거래 모델에는 채용, 잔류, 계약직의 정규직 전환 및 교육 비용이 포함되어야 합니다. 핵심 인물 위험은 전환 기간 내에 역량을 이전할 수 없을 때 밸류에이션에 영향을 미칠 수 있습니다. 경영진은 명시된 지식 이전 증거에 대한 진행 상황을 보고해야 합니다.
18 고객 및 규제 수용성 검토
고객 계약은 소프트웨어 성능, 보안, 감사, 승인 및 변경 의무를 규정할 수 있습니다. 매수자는 동의, 통지, 재인증 또는 특정 인력 지정을 요구하는 계약을 식별해야 합니다. 자동으로 이전되는 매출과 고객 수용에 따라 달라지는 매출을 구분해야 합니다.
정부 및 핵심 인프라 고객은 기술 데이터, 보안 인가, 호스팅 또는 공급망 제한을 부과할 수 있습니다. 매수자는 자사의 소유권, 자금 조달, 인력 및 운영 모델이 여전히 적격 요건을 충족하는지 평가해야 합니다. 규제 라이선스와 주파수 권리는 소프트웨어 법인 외부에 있으면서도 서비스 제공에 필수적일 수 있습니다.
상업 모델은 불확실한 갱신 및 동의에 확률 가중치를 부여해야 합니다. 대가는 검증된 이전 또는 유지된 매출에 조건부로 연동될 수 있습니다. 매수자는 운영 전제 조건이 이전되지 않는 계약에 대해 전액 가치를 지급하는 것을 피해야 합니다.
19 실사를 밸류에이션과 연결하십시오
소프트웨어 실사는 현금흐름, 타이밍, 리스크 및 옵션 존속기간을 통해 가치를 변화시킵니다. 보완 작업은 비용을 증가시킵니다. 권리 누락은 수익화 가능 매출을 감소시킬 수 있습니다. 운영 취약성은 서비스 중단 확률을 높일 수 있습니다. 빌드 통제가 약하면 제품 개발이 지연될 수 있습니다. 강력한 증거는 통합 충당금을 낮추고 갱신에 대한 신뢰를 높이는 데 기여할 수 있습니다.
밸류에이션 브리지는 조정을 중복해서는 안 됩니다. 반복적인 지원 비용은 예상 현금흐름에 반영해야 합니다. 일회성 재구축은 거래 또는 통합 용도에 반영해야 합니다. 이분형 권리 결함은 할인율 프리미엄보다는 제외, 에스크로 또는 조건으로 처리해야 할 수 있습니다.
매수자는 기본, 하방 및 심각 시나리오를 제시해야 합니다. 각 시나리오는 운영 가정, 증거 및 경영진 조치를 식별해야 합니다. 터미널 밸류는 지속적인 유지보수, 부품 노후화, 공급업체 집중도 및 제품을 갱신할 수 있는 능력을 반영해야 합니다.
20 발견 사항을 거래 메커니즘으로 전환하십시오
중요 발견 사항에는 책임자와 거래 대응 방안이 있어야 합니다. 가능한 대응 방안에는 가격 인하, 보류 금액, 에스크로, 언아웃, 배상, 종결 조건, 코버넌트, 전환 서비스, 라이선스 계약 승계(노베이션), 핵심 인력 관련 약정 또는 제외 자산이 포함됩니다.
조건은 객관적으로 검증 가능해야 합니다. 완전한 소스를 제공하라는 요구는 저장소, 브랜치, 산출물 및 인수 테스트가 정의되지 않으면 약합니다. 빌드 조건은 환경, 입력값, 성공적인 테스트 스위트 및 배포 패키지를 명시할 수 있습니다. 접근 조건은 신원, 권한, 키 및 검증된 로그인을 명시할 수 있습니다.
공개 프로세스는 버전 관리된 증거를 보존해야 합니다. 매수자는 각 진술을 뒷받침하는 산출물과 예외를 승인한 주체를 기록해야 합니다. 기술 부속서는 엔지니어링과 법률 자문의 검토를 거쳐 법적 문언이 운영 현실과 일치하도록 해야 합니다.
21 종결 컨트롤룸을 설계하십시오
종결은 운영상 변화로 관리해야 합니다. 컨트롤룸은 법적 완료, 자격 증명 이전, 공급업체 계약 승계(노베이션), 클라우드 테넌시, 코드 리포지토리, 서명 권한, 고객 통지, 모니터링 및 사고 대응 범위를 조정합니다.
계획은 명시적인 진행, 보류 및 롤백 기준을 사용해야 합니다. 각 단계는 증거, 시점, 책임자 및 대체 방안을 식별합니다. 되돌릴 수 없는 조치가 발생하기 전에 핵심 접근 권한을 테스트해야 합니다. 당사자들은 최고 위험 구간 동안 공동 대응 범위를 유지해야 합니다.
매수자는 로그와 구성 스냅샷을 보존해야 합니다. 이러한 기록은 이전 시점의 상태를 입증하고 이후 조사를 지원합니다. 종결 후 첫 릴리스는 즉흥적인 통합 테스트가 아니라 합의된 보증 프로세스를 따라야 합니다.
22 첫 100일 계획을 수립하십시오
첫 100일 동안 통제를 안정화하고 우선순위 증거 격차를 해소하며 집중도를 낮춰야 합니다. 초기 조치에는 접근 권한 재인증, 자격 증명 교체, 클린 빌드, 의존성 확인, 핵심 백로그 보완, 복구 테스트, 직원 유지 및 공급업체 거버넌스가 포함됩니다.
아키텍처 변경은 증거를 따라야 합니다. 즉각적인 플랫폼 마이그레이션은 소유권 전환과 기술 변경을 결합하여 회피 가능한 리스크를 만들 수 있습니다. 통합 팀은 미션 윈도우, 고객 약정 및 복구 역량을 기준으로 변경 순서를 정해야 합니다.
이사회는 빌드 재현성, 치명적 취약점, 핵심 키 접근, 공급업체 노베이션, 고객 동의, 복구 테스트, 지식 이전 및 지출을 포괄하는 간결한 대시보드를 받아야 한다. 보고된 완료에는 객관적 증거가 요구되어야 한다.
23 지속적인 소프트웨어 가치 관리
종결 후 거버넌스는 소프트웨어 건전성을 상업적·재무적 성과와 연결해야 한다. 엔지니어링 지표에는 배포 신뢰성, 결함 유출, 취약점 경과 기간, 빌드 무결성, 복구 성능 및 의존성 상태가 포함된다. 상업적 지표에는 서비스 가용성, 갱신, 제공 지연 및 지원 비용이 포함된다.
제품 로드맵은 필수 유지보수, 고객 약정, 보안 개선 및 성장 투자를 구분해야 한다. 유지보수 이연은 단기 이익을 부풀리면서 미래 현금 창출을 약화시킬 수 있다. 투자위원회는 그 차이를 이해해야 한다.
매수자는 핵심 권리, 구성 및 공급업체에 대한 증거 등록부를 유지해야 한다. 소유권, 라이선스, 지원 또는 아키텍처의 변경은 인수 논리를 바꿀 수 있다. 연간 보증과 정기적인 거래 준비성 검토는 재융자 또는 엑시트를 위한 선택권을 보존한다.
24 가상 거래 사례
가상 대상은 통신, 지구 관측 및 호스팅 탑재체 임무 전반에 걸쳐 18개 위성을 지원한다. 플랫폼에는 임무 계획, 명령 검증, 텔레메트리 처리, 비행 역학, 자동화 및 고객 제공이 포함된다. 매출은 연간 소프트웨어 및 운영 계약을 통해 발생한다.
실사 결과 강한 고객 유지력과 우수한 엔지니어링 역량이 확인된다. 또한 다섯 가지 거래 익스포저를 식별한다. 프로덕션 빌드에는 문서화되지 않은 상용 도구가 필요하다. 두 개의 라이브러리는 매도인의 모회사에 라이선스되어 있으며 자동으로 이전될 수 없다. 한 명의 관리자가 핵심 프로덕션 및 서명 프로세스를 통제한다. 치명적 취약점 개선은 임무 윈도 주변으로 연기되었다. 고객별 어댑터에는 양도 증거가 불완전한 기여물이 포함되어 있다.
매수자는 USD 84 million 헤드라인 가치에서 USD 25 million의 총 차감액을 적용해 이러한 발견 사항을 가격에 반영한다. 정의된 증거 게이트가 충족되면 추가 USD 6 million 언아웃이 가능하다. 이 구조는 매도인의 개선 참여를 보존하면서 종결 시점의 매수자 현금을 보호한다.
25 의사결정 원칙
첫째, 인수한 임무 역량과 그 운영 범위를 정의한다. 둘째, 모든 핵심 배포 산출물을 통제된 소스, 빌드 및 승인 증거로 추적한다. 셋째, 소유권, 접근권, 권리 및 운영 권한을 분리한다. 넷째, 공급업체 및 인력 집중도를 연속성에 매핑한다. 다섯째, 복구 및 거래 전환을 테스트한다. 여섯째, 해결되지 않은 각 의존성을 현금, 조건 또는 계약적 보호로 전환한다.
이러한 원칙은 엔지니어링, 재무, 운영 및 법무 팀을 위한 공통 언어를 만든다. 또한 증거 요청과 승인 테스트가 구체화되므로 거래 속도를 개선한다.
매수자의 목표는 임무 성과에 대한 입증 가능한 통제다. 그러한 통제는 연속성, 고객 신뢰, 통합 및 방어 가능한 밸류에이션을 뒷받침한다.
26 아키텍처 및 기술 부채 검토
아키텍처 실사는 시스템이 임무 계획, 비행 역학, 명령 검증, 텔레메트리, 자동화, 아이덴티티, 데이터 저장소 및 외부 인터페이스를 어떻게 분리하는지 설명해야 한다. 매수자는 신뢰 경계, 장애 도메인, 공유 서비스 및 변경 시 여러 임무에 영향을 줄 수 있는 구성요소를 식별해야 한다. 아키텍처 다이어그램은 배포된 토폴로지, 네트워크 흐름 및 저장소 소유권과 대조되어야 한다.
기술 부채는 초래하는 결과를 통해 설명되어야 합니다. 오래된 프로그래밍 언어라도 전문성, 테스트 및 툴체인이 갖춰져 있으면 관리 가능한 상태로 유지될 수 있습니다. 최신 서비스라도 소유권, 관측 가능성 또는 복구 체계가 없으면 취약할 수 있습니다. 실사 팀은 각 중대한 기술 부채 항목의 비용, 실행 순서 및 운영 리스크를 추정해야 합니다.
기술 부채 분류는 유지보수성, 보안, 성능, 확장성, 노후화 및 컴플라이언스를 구분해야 합니다. 상업 모델은 성장 또는 고객 유지에 제약을 주는 범주를 반영해야 합니다. 개선 계획은 구분 없는 백로그를 제시하기보다 의존성과 임무 수행 시간대를 식별해야 합니다.
27 관측 가능성과 인시던트 증거 평가
미션 컨트롤의 가치는 비정상 행동을 탐지하고 설명하는 능력에 달려 있습니다. 구매자는 로그, 지표, 트레이스, 알림, 대시보드, 보존, 시계 동기화 및 인시던트 기록을 검토해야 합니다. 데이터가 어디에서 생성되는지, 누가 접근할 수 있는지, 시스템 또는 공급업체 장애 후에도 기록이 유지되는지 확인해야 합니다.
알림 품질은 표본 검토할 가치가 있습니다. 조치 불가능한 알림이 대량으로 발생하면 중대한 이벤트를 가릴 수 있습니다. 알림이 희박하면 커버리지가 제한적임을 보여줄 수 있습니다. 팀은 선별된 인시던트를 기록된 텔레메트리, 대응 조치, 근본 원인 분석 및 시정 작업과 비교해야 합니다. 지속적인 개선 없이 반복되는 인시던트는 통제 취약점을 나타냅니다.
거래 계획은 모니터링의 연속성을 보존해야 합니다. 계정 마이그레이션, 클라우드 분리 또는 도구 교체는 사각지대 기간을 만들 수 있습니다. 종결 계획은 어떤 알림이 계속 활성화되는지, 누가 수신하는지, 전환 기간 동안 공동 팀이 이벤트를 어떻게 처리하는지 정의해야 합니다. 안정적인 모니터링의 증거는 더 짧은 전환 서비스 기간을 뒷받침할 수 있습니다.
28 확장성 및 위성군 확장 테스트
과거 성과만으로 플랫폼이 구매자가 계획한 위성군을 지원할 수 있음이 입증되지는 않습니다. 팀은 위성, 접촉, 텔레메트리 양, 명령 부하, 고객 인터페이스, 동시 운영자 및 지상국과 같은 확장 동인을 식별해야 합니다. 관측된 최대 사용률과 용량 여유를 검토해야 합니다.
부하 테스트는 대표적인 메시지 패턴과 장애 조건을 사용해야 합니다. 우주 운영에서는 발사, 시운전, 이상 징후 및 접촉 윈도 주변에 짧은 고강도 활동 기간이 생길 수 있습니다. 평균 사용률은 이러한 기간의 대기열, 데이터베이스 경합 또는 운영자 과부하를 숨길 수 있습니다.
성장 시나리오에는 인프라, 라이선스, 지원 및 인력 비용이 포함되어야 합니다. 기술적으로 확장 가능한 플랫폼도 위성당 공급업체 가격이나 희소 전문인력으로 인해 상업적 한계에 직면할 수 있습니다. 밸류에이션 모델은 성장 수익을 이를 실현하는 데 필요한 자본 및 운영비와 정합시켜야 합니다.
29 인공지능 기능을 신중하게 평가
대상 기업은 이상 탐지, 스케줄링, 이미지 처리, 예측 유지보수 또는 운영자 지원을 위해 머신러닝을 사용할 수 있습니다. 실사에서는 지원되는 정확한 의사결정, 모델 소유자, 학습 데이터 권리, 검증, 모니터링, 인간 감독 및 장애 대응을 식별해야 합니다. 마케팅 설명은 운영 가치에 대한 제한적인 증거만 제공합니다.
구매자는 주장된 성과를 정의된 기준선 및 대표 임무 데이터와 비교해야 합니다. 오탐, 미탐, 드리프트, 재학습, 버전 관리 및 엣지 케이스를 검토해야 합니다. 평균 탐지 성능을 개선하는 모델이라도 실패 모드가 불투명하면 명령 의사결정에 부적합할 수 있습니다.
엔지니어링 또는 운영에 사용되는 생성형 도구는 민감 데이터, 코드 출처 및 출력 검토에 대한 거버넌스가 필요합니다. 제품 로드맵은 입증된 고객 가치와 실험적 역량을 분리해야 합니다. 밸류에이션은 권리, 성과, 배포 및 현금 전환이 입증된 경우에만 AI 관련 수익을 인식해야 합니다.
30 수출통제 및 주권 접근 제약 검토
위성 소프트웨어, 기술 데이터 및 서비스는 수출통제, 제재, 보안등급 분류 및 주권적 접근 요건의 적용을 받을 수 있습니다. 매수자는 통제 대상 품목, 라이선스, 국적, 소재지, 클라우드 리전 및 고객 제한을 매핑해야 합니다. 전문 법률 자문이 적용 법제를 해석해야 합니다.
소유권이 이전되더라도 운영상 접근이 제한될 수 있습니다. 일부 고객은 보안 인증을 받은 인력, 국내 호스팅 또는 분리된 지원을 요구할 수 있습니다. 매수자의 소유 및 금융 구조는 심사나 동의를 촉발할 수 있습니다. 이러한 요인은 통합 설계와 운영 중앙화 능력에 영향을 미칩니다.
거래 모델에는 컴플라이언스 인력, 분리된 환경, 라이선스 일정 및 잠재적 매출 제한이 포함되어야 합니다. 종결 조건은 연속성에 필요한 승인을 다루어야 합니다. 경영진은 포괄적 확언을 피하고 각 승인이 포괄하는 정확한 범위를 식별해야 합니다.
31 투자위원회 증거 패키지 작성
투자위원회는 기술적 발견과 경제적 결정 사이의 간결한 연결을 필요로 합니다. 패키지는 인수 역량, 매출 의존도 및 핵심 통제 지점으로 시작해야 합니다. 소스 및 빌드 증거, 권리 지위, 공급업체 맵, 운영 복원력, 고객 동의 및 인력 집중도를 제시해야 합니다.
각 중대한 발견은 증거 상태, 현금 영향, 제안된 처리 방식, 책임 소유자 및 잔여 위험을 보여주어야 합니다. 위원회는 검증된 격차를 경영진 추정 및 향후 개선 약속과 구분할 수 있어야 합니다. 시나리오 분석은 지연과 결합된 실패의 영향을 보여주어야 합니다.
승인에는 조건, 위임 권한 및 종결 후 보고를 명시해야 합니다. 그런 다음 증거 패키지는 통합 거버넌스의 기준선이 됩니다. 이러한 연속성은 실사 결과가 종결 후 사라질 위험을 줄이고 이후 가치 창출에 대한 책임을 뒷받침합니다.
32 매도자로부터 분리 계획 수립
캐브아웃에는 애플리케이션, 인프라, 아이덴티티, 네트워크, 계약, 데이터 및 인력을 포괄하는 분리 모델이 필요합니다. 매수자는 매도자에게 남는 서비스, 이전되는 서비스 및 재구축해야 하는 서비스를 식별해야 합니다. 각 항목에는 임시 운영 방식, 목표 상태, 비용, 의존성 및 종료 기준이 있어야 합니다.
전환서비스계약은 측정 가능한 서비스와 운영 책임을 기술해야 합니다. 서비스 수준, 보안 의무, 사고 조정, 접근, 변경 통제, 데이터 반환, 감사 권리, 가격 및 종료를 명시해야 합니다. 합리적 지원을 제공하겠다는 포괄적 약속은 핵심 임무 요구를 해결하지 못한 채 남길 수 있습니다.
분리 일정은 임무 제약을 따라야 합니다. 아이덴티티 또는 네트워크 변경은 모니터링 및 명령 경로에 영향을 줄 수 있습니다. 데이터 마이그레이션은 이력 및 감사 증거에 영향을 줄 수 있습니다. 공급업체 노베이션은 지원 권리를 변경할 수 있습니다. 당사자들은 고위험 변경을 단계적으로 시행하고 승인 기준이 충족될 때까지 롤백을 보존해야 합니다.
전환 서비스가 종료되기 전에 엑시트 준비 상태를 테스트해야 합니다. 매수자는 독립적인 접근, 빌드, 배포, 모니터링, 지원 및 복구를 입증해야 합니다. 또한 서비스를 중단하지 않고 매도자 계정과 데이터를 제거할 수 있는지 확인해야 합니다. 모든 연장에는 명확한 사유, 가격 및 개선 책임자가 있어야 합니다.
분리 비용은 거래 모델에 포함되어야 합니다. 여기에는 중복 인프라, 임시 라이선스, 마이그레이션 엔지니어링, 보안 테스트, 고객 검증 및 운영 중복이 포함됩니다. 추정치는 확정 견적과 경영진 가정을 구분해야 합니다. 자금이 확보되고 거버넌스가 갖춰진 분리 계획은 연속성을 보호하고 거래가 매도자에 대한 무기한 의존성을 떠안지 않도록 합니다.
이사회는 모든 미션 크리티컬 서비스가 독립적으로 운영될 때까지 주간 분리 대시보드를 받아야 합니다. 대시보드는 기한이 지난 의존성, 테스트된 엑시트, 미해결 고객 의무, 예상 비용 및 다음 비가역적 조치를 식별해야 합니다. 종결에는 엔지니어링, 운영, 보안, 재무 및 관련 서비스 소유자의 증거가 필요해야 합니다.
부록 A 실사 증거 등록부
증거 등록부는 질문, 요청 산출물, 출처 소유자, 버전, 검토 결과, 예외, 재무적 영향 및 거래 대응을 식별해야 합니다. 결론을 재현할 수 있도록 가상 데이터룸과 연결된 상태를 유지해야 합니다.
고우선순위 증거에는 운영 인벤토리, 저장소 맵, 클린 빌드 결과, 배포 추적, 권한 인벤토리, 라이선스 일람, SBOM, 취약점 백로그, 복구 테스트, 고객 동의 맵 및 핵심 인력 계획이 포함됩니다. 각 항목은 포함되는 정확한 시스템과 구성을 식별해야 합니다.
표본 추출은 리스크 기반이어야 합니다. 팀은 대표적인 고영향 임무, 핵심 인터페이스, 최근 릴리스, 긴급 변경 및 오래된 구성요소를 선택해야 합니다. 표본은 통제 설계와 실제 실행을 모두 테스트해야 합니다.
부록 B 밸류에이션 방법
예시 방법은 구매자의 상업 모델에서 도출된 기업가치로 시작합니다. 그런 다음 예측 현금흐름을 반복 유지보수 및 공급업체 비용에 맞게 조정합니다. 일회성 시정, 분리 및 전환 비용은 용도에 포함됩니다. 고객 동의가 필요한 매출은 확률 가중치를 적용합니다. 권리 흠결 및 운영 조건은 공제, 에스크로 또는 우발대가를 통해 처리합니다.
시나리오 분석은 관련 리스크를 결합해야 합니다. 공급업체 지연은 시정과 고객 수용을 지연시킬 수도 있습니다. 핵심 인력의 이탈은 연속성과 지식 이전을 모두 약화시킬 수 있습니다. 상관된 하방 리스크는 명시적으로 다뤄야 합니다.
본 문서의 어떤 가상 수치도 확인된 거래를 나타내지 않습니다. 본 사례는 증거가 밸류에이션 및 거래 구조와 어떻게 연결될 수 있는지 보여줍니다.
부록 C 클로징 인수 테스트
인수 테스트는 저장소 접근, 클린 빌드, 테스트 실행, 패키지 서명, 비운영 배포, 구성 복원, 모니터링, 특권 접근, 공급업체 지원 및 복구를 포함해야 합니다. 당사자들은 서명 전에 테스트 데이터, 환경, 합격 기준 및 증거에 합의해야 합니다.
테스트는 실제 운영 중단을 피해야 합니다. 프로덕션 변경은 임무 승인과 별도 통제를 필요로 합니다. 비운영 테스트도 통제된 소스에서 배포 가능한 산출물까지의 체인을 검증할 수 있습니다.
실패한 테스트에는 사전 정의된 결과가 있어야 합니다. 여기에는 시정, 에스크로, 클로징 지연, 대가 감액 또는 자산 제외가 포함될 수 있습니다. 대응은 실패의 운영 및 재무적 중요성에 부합해야 합니다.
부록 D 의사결정 그림 및 표
예시적 증거 진행; 수치는 가상이며 특정 회사를 나타내지 않습니다.
점수가 높을수록 가상 사례에서 의존도가 더 높음을 나타냅니다.
제안된 순서이며, 실제 일정은 거래 사실관계와 미션 제약에 따라 달라집니다.
전적으로 가상의 수치이며, USD백만입니다.
제안된 순서이며, 미션 윈도우와 고객 의무에 따라 달라질 수 있습니다.
| 증빙 | 거래 관련 질문 | 수용 지표 | 격차 대응 |
|---|---|---|---|
| 리포지토리 인벤토리 | 모든 중요 소스가 형상 관리되고 있습니까? | 프로덕션 구성요소는 명명된 리포지토리로 추적됩니다. | 완료 조건 또는 범위가 지정된 제외 항목 |
| 빌드 정의 | 클린 환경에서 릴리스를 생성할 수 있습니까? | 문서화된 입력값을 기반으로 한 성공적인 통제 빌드 | 홀드백 및 시정 계획 |
| 출처 | 배포된 아티팩트를 추적할 수 있는가? | 버전, 종속성, 승인 및 서명 연계 | 리스크 준비금 및 통제 시정 |
| 생성된 아티팩트 | 모델과 생성기를 이용할 수 있는가? | 통제된 소스로부터 재빌드 가능 | 라이선스 또는 자산 이전 조건 |
제안된 거래의 증빙 요건.
| 종속성 | 증빙 | 주요 익스포저 | 거래 처리 |
|---|---|---|---|
| 직원 작성 코드 | 고용 및 발명 귀속 조항 | 소유권 공백 | 양도 및 보증 |
| 계약자 작업물 | 업무기술서 및 양도 | 수정 또는 양도 제한 | 특정 양도 또는 배상 |
| 상용 소프트웨어 | 라이선스 및 지원 조건 | 양도 금지, 해지 또는 가격 재설정 | 노베이션, 대체 또는 공제 |
| 오픈소스 소프트웨어 | SBOM, 라이선스 및 배포 기록 | 컴플라이언스 및 유지보수 | 시정 계획 및 지속 거버넌스 |
| 고객 접점 | 계약 및 기여 이력 | 기존 고객으로 사용 제한 | 동의 또는 우발가치 |
제안된 법적 및 운영상 종속성 분류.
| 항목 | USD 백만 | 증거 근거 | 처리 방식 |
|---|---|---|---|
| 헤드라인 기업가치 | 84 | 사업 모델 | 기초 가치 |
| 시정 및 전환 | -9 | 구축, 취약성 및 분리 계획 | 클로징 공제 |
| 권리 및 종속성 | -7 | 라이선스 및 출처 공백 | 공제 또는 에스크로 |
| 집중도 및 취약성 | -5 | 접근권한 및 핵심인력 검토 | 통합 준비금 |
| 고객 수용 | -4 | 동의 및 인터페이스 증빙 | 우발대가 |
| 종결 시 현금 가치 | 59 | 총괄 프레임워크 | 예시 결과 |
전적으로 가정에 불과함; USD백만.
| 지배권 | 이전 전 증빙 | 종결 조치 | 종결 후 검증 |
|---|---|---|---|
| 저장소 | 접근 목록 및 보호된 브랜치 | 관리자 이관 | 접근 권한 및 로그 대조 |
| 서명 | 키 인벤토리 및 승인 체계 | 키 교체 또는 재등록 | 서명된 비운영 릴리스 테스트 |
| 운영 환경 접근 권한 | 권한 인벤토리 | 판매자 전용 계정 회수 | 사용자 및 서비스 접근 권한 재인증 |
| 공급업체 | 계약 및 동의 일람 | 노베이션 실행 | 지원 및 사고 연락처 확인 |
| 복구 | 최근 훈련 및 백업 인벤토리 | 스냅샷 보존 | 통제된 복원 실행 |
제안된 통제; 실제 순서는 임무 제약에 따라 달라집니다.
| 측정 | 30일차 증거 | 60일차 증거 | 100일차 증거 |
|---|---|---|---|
| 빌드 통제 | 클린 환경 구축됨 | 핵심 제품 재현됨 | 정기 릴리스 증거 완료 |
| 접근 | 관리자 재인증 완료 | 서비스 계정 할당됨 | 예외 사항 종결 또는 수용 |
| 취약점 | 핵심 백로그 검증 완료 | 우선순위 개선 조치 테스트 완료 | 지속 가능한 서비스 수준 운영 중 |
| 공급업체 | 핵심 의존성 확인 완료 | 노베이션 및 대체 계약 진행 | 거버넌스 및 종료 계획 승인 완료 |
| 지식 | 핵심 역할 유지 | 런북 및 페어링 진행 중 | 독립적 운영 커버리지 테스트 완료 |
제안된 증거 마일스톤.
| 발견 사항 | 현금 영향 | 계약 메커니즘 | 해제 증빙 |
|---|---|---|---|
| 양도 불가능한 의존성 | USD 7 million | 에스크로 또는 대금 공제 | 체결된 계약상 지위 이전 또는 적격 대체 |
| 빌드 취약성 | USD 4 million | 거래 종결 조건 | 성공적인 클린 빌드 및 테스트 |
| 핵심 인물 의존도 | USD 3 million | 리텐션 연계 유보금 | 지식 이전 마일스톤 |
| 고객별 권리 | USD 4 million | 어닝아웃 | 동의 및 유보 현금 회수 |
전적으로 가상의 현금 효과; USD백만.
| 결정 영역 | 녹색 증빙 | 황색 조건 | 적색 조건 |
|---|---|---|---|
| 소스 코드 관리 | 완전하며 추적 가능한 저장소 | 통제된 경미한 공백 | 핵심 소스 또는 이력 누락 |
| 구축 | 반복 가능한 통제된 릴리스 | 자금이 확보된 보완 조치가 있는 수동 단계 | 빌드를 재현할 수 없음 |
| 권리 | 양도 가능하고 문서화된 권리 | 보호 조치를 갖춘 동의 대기 상태 | 중대한 권리 이용 불가 |
| 운영 | 독립적인 인력 커버리지 | 테스트된 전환을 갖춘 집중 리스크 | 대체 인력 없는 특정인 의존 |
| 복구 | 최근 성공적인 복구 | 일부 범위 또는 오래된 실시 | 복구 기능이 검증되지 않았거나 사용할 수 없음 |
제안된 의사결정 임계값.
출처
- 미국 국립표준기술연구소, SP 800-218 보안 소프트웨어 개발 프레임워크 버전 1.1, 2022. 원출처 읽기
- 미국 국립표준기술연구소, SP 800-161 개정 1 시스템 및 조직을 위한 사이버보안 공급망 위험 관리 실무, 2022. 원출처 읽기
- 미국 국립표준기술연구소, 공급망 내 소프트웨어 보안 지침, 2024년 개정. 원출처 읽기
- 미국 국립표준기술연구소, 사이버보안 프레임워크 2.0, 2024. 원출처 읽기
- 미국 국립표준기술연구소, NISTIR 8401 위성 지상 세그먼트: 위성 명령 및 제어에 사이버보안 프레임워크 적용, 2022. 원출처 읽기
- 미국 국립표준기술연구소, SP 800-53 개정 5 정보 시스템 및 조직을 위한 보안 및 개인정보 보호 통제. 원출처 읽기
- 미국 항공우주국, NASA 소프트웨어 엔지니어링 및 보증 핸드북 NASA-HDBK-2203. 원출처 읽기
- 미국 항공우주국, SWE-042 소스 코드 전자적 접근. 원출처 읽기
- 미국 항공우주국, SWE-158 보안 취약성에 대한 소프트웨어 평가. 원출처 읽기
- 미국 항공우주국, SWE-206 소프트웨어 입력 자동 생성. 원출처 읽기
- 미국 항공우주국, NPR 7150.2 NASA 소프트웨어 엔지니어링 요구사항. 원출처 읽기
- 미국 항공우주국, NASA-STD-8739.8 소프트웨어 보증 및 소프트웨어 안전 표준. 원출처 읽기
- 미국 항공우주국, NASA-STD-1006A 우주 시스템 보호 표준. 원출처 읽기
- 미국 항공우주국, 우주 보안 모범 사례 가이드. 원출처 읽기
- 사이버보안 및 인프라 보안청, 개발자를 위한 소프트웨어 공급망 보안 권장 실무, 2023. 원출처 읽기
- 사이버보안 및 인프라 보안청, 소프트웨어 자재 명세서. 원출처 읽기
- 사이버보안 및 인프라 보안청, 설계 단계부터 보안 내재화. 원출처 읽기
- 사이버보안 및 인프라 보안청, 연방 정부 사이버보안 사고 및 취약점 대응 플레이북. 원출처 읽기
- 유럽 우주국, 임무 운영용 소프트웨어 제품. 원출처 읽기
- 유럽 우주국, SPACE-SHIELD 악성 공급망 기능 및 소프트웨어 취약점. 원출처 읽기
- 유럽연합 사이버보안청, ENISA 우주 위협 환경 2025. 원출처 읽기
- 우주 데이터 시스템 자문위원회, 임무 운영 및 정보 관리 서비스. 원출처 읽기
- 우주 데이터 시스템 자문위원회, 보안 워킹그룹 간행물. 원출처 읽기
- 미국 우주상업국, 우주 정책 지시 5호: 우주 시스템 사이버보안 원칙. 원출처 읽기
- 영국 국가사이버보안센터, 이사회용 사이버 보안 툴킷. 원출처 읽기
- 오픈 월드와이드 애플리케이션 보안 프로젝트, 소프트웨어 구성요소 검증 표준. 원출처 읽기
- 오픈 월드와이드 애플리케이션 보안 프로젝트, 소프트웨어 보증 성숙도 모델. 원출처 읽기
- 리눅스 재단, SPDX 소프트웨어 패키지 데이터 교환. 원출처 읽기
- 국제표준화기구(ISO), ISO IEC 27001 정보보안 경영시스템. 원출처 읽기
- 유럽 우주 표준화 협력기구(ECSS), ECSS 소프트웨어 엔지니어링 표준. 원출처 읽기
