정보보안의 원리
웹 416쪽 무료 · 종이책 B5 416쪽
정보보안의 원리 · 방향 6
© K-BOOKS · 무료 웹 열람용 콘텐츠입니다. 무단 복제·저장·인쇄·재배포를 제한합니다.
열네 번째 발걸음빌드 과정도 프로그램의 일부로 보호한다
당신이 직접 작성한 코드는 전체 프로그램의 일부일 수 있습니다. 외부 라이브러리, 빌드 도구, 컨테이너 이미지, 배포 스크립트가 연결되어 최종 실행 파일을 만듭니다. 코드 검토를 통과한 저장소가 안전하더라도 중간 과정에서 다른 구성요소가 들어오면 배포 결과가 달라질 수 있습니다. 그래서 소프트웨어 공급망을 함께 보아야 합니다.
의존성은 프로그램이 사용하는 다른 소프트웨어입니다. 직접 지정한 라이브러리가 또 다른 라이브러리를 사용하면 간접 의존성도 생깁니다. 이름과 버전, 출처를 관리하고 신뢰할 저장소에서 가져오며 변경 이력을 확인합니다. 널리 쓰인다는 이유만으로 모든 버전이 안전하다고 가정하지 않습니다. 보안패치가 나오면 실제 사용하는 버전과 기능, 배포 위치를 알아야 영향을 판단할 수 있습니다.
SBOM은 소프트웨어의 구성요소를 식별하는 명세입니다. 어떤 재료가 들어 있는지 알게 하지만 그 목록 자체가 안전성을 보증하지는 않습니다. 알려진 취약점 정보와 실제 사용 조건을 대조하고, 적용된 배포본과 연결해야 합니다. 개발용 목록과 실제 실행되는 이미지가 다르면 필요한 조치 대상을 놓칠 수 있습니다.
빌드와 배포의 권한도 분리합니다. 코드를 제출할 수 있는 사람, 검토·승인하는 사람, 배포를 실행하는 서비스 계정에 필요한 권한이 다릅니다. 자동화 계정에 불필요하게 넓은 운영 권한을 주면 빌드 설정의 작은 변경이 운영 시스템의 변경으로 이어질 수 있습니다. 보호된 브랜치와 검토, 배포 승인, 단기 증표 등은 실제 변경 흐름에 맞게 적용합니다.
비밀키와 API 토큰을 소스 코드나 로그에 넣지 않습니다. 비밀 관리 기능을 통해 필요한 실행 주체에게 필요한 시간 동안 전달하고, 노출되면 회수·교체할 수 있게 합니다. 저장소의 현재 파일에서 지웠어도 과거 이력과 빌드 로그에 남아 있을 수 있습니다. 비밀을 삭제한 조치와 그 증표를 더 이상 쓸 수 없게 한 조치는 구분해야 합니다.
서명된 배포 파일은 무결성과 출처를 검증할 근거를 줄 수 있습니다. 그러나 서명자가 잘못된 코드를 빌드했거나 서명키가 악용되었다면 “서명이 유효함”만으로 안전한 프로그램이라는 결론을 낼 수 없습니다. 어떤 코드와 의존성으로 어느 과정에서 만들어졌는지에 관한 출처 이력도 함께 관리합니다. 검증한 산출물이 실제 배포된 산출물과 동일한지 이어서 확인해야 합니다.
DevSecOps는 개발·운영의 지속적인 변경 과정에 보안 활동을 통합하는 관점으로 이해할 수 있습니다. 검사를 자동화하되 실패를 무시하는 예외가 상시 경로가 되지 않게 관리합니다. 자동화는 반복을 돕고, 위험의 수용과 책임은 조직의 판단으로 남습니다. 공급망의 변화와 발견된 취약점은 배포 이후에도 계속 추적해야 합니다.
함께 따라가기 · 취약한 라이브러리를 발견한 날
문서 변환 라이브러리의 특정 버전에 취약점이 공개되었다고 가정합니다.
구성요소 목록으로 해당 버전을 포함하는 서비스를 찾습니다. 이름이 비슷한 다른 패키지와 혼동하지 않고 실제 배포된 이미지까지 대조합니다.
문서가 공격 가능한 경로로 들어오는지, 사용 기능이 영향을 받는지, 임시 통제가 있는지 살펴 우선순위를 정합니다. 목록에서 버전이 발견된 사실과 실제 악용 조건을 구분합니다.
패치한 버전으로 빌드하고 정상 변환·실패 처리·자원 제한을 확인합니다. 배포 후 운영 중인 서비스가 바뀐 산출물을 실제로 쓰는지 확인합니다.
같은 구성요소를 다음에 놓치지 않도록 목록과 알림·검토 절차를 갱신합니다. 코드 한 줄의 수정으로 끝나지 않고 반복 원인을 줄이는 활동으로 연결합니다.
깨달음공급망 보안은 재료를 알고, 바뀐 재료를 검증하고, 최종 사용 위치까지 연결하는 일입니다.
이 브라우저에 학습 기록을 저장합니다.