보안검증·취약점관리·DevSecOps

스캐너 경고는 0건인데 회수한 문서가 계속 보인다

앞의 한시 문서 공유 기능에 자동 소스 검사를 적용했다. 알려진 경고는 없었지만, 권한을 회수한 감사자가 새 요청으로 문서를 계속 내려받았다. 도구가 조사한 코드 패턴과 실제 업무의 회수 조건은 같은 질문이 아니었다.

취약점 조치도 설치 건수만 세면 비슷한 오류가 생긴다. 패치를 설치했지만 실행 중인 프로세스는 옛 버전일 수 있고, 서버를 격리했지만 결함 자체는 남아 있을 수 있다. 이 절은 요구별 시험과 결과, 취약점의 우선순위와 실제 수정·재시험을 구분한다. 모든 시험표·서버 수·판단 사례는 자체 교육용이며 실측 성과나 공식 인증 결과가 아니다.

요구와 기대값에서 다시 시작하기

보안엔지니어링은 요구·위협·설계·검증·운영 개선을 잇는 생명주기 활동이다. 한시 공유의 추적표는 지정 수신자·버전·기간·회수·근거 부재를 기대 결과와 연결했다. 여기서는 그 정의를 다시 만들지 않고 시험의 실제 결과와 수정 완료의 증거를 판정한다.

1. 발견·판단·조치·재시험의 연결

보안검증과 취약점 조치 관리는 보안 요구에 대한 증거를 수집·평가하고, 발견한 결함의 영향과 우선순위를 정해 조치한 뒤 실제 적용·재시험과 재발 방지까지 추적하는 활동이다.

도구의 경고는 조사할 후보이고, 재현된 결함은 확인된 문제이며, 조치 완료는 정한 범위에서 수정과 재검증이 확인된 상태다. 셋을 같은 발견 건수로 합치지 않는다. 같은 결함을 두 도구가 알렸다면 원인·구성요소·영향 자산을 대조해 연결하되, 증거가 다른 두 결함을 제목이 비슷하다는 이유만으로 하나로 지우지도 않는다.

가상 공유 기능에서는 권한 회수 뒤 문서가 제공되는지를 실제 요청과 제공 기록으로 확인한다. 테스트가 코드를 실행했는지보다 보호하려던 조건을 제대로 관측했는지가 중요하다. 화면에 오류가 보여도 실제 문서 바이트가 먼저 전송됐다면 미제공 요구를 통과한 것이 아니다.

2. 검사의 관측 대상부터 고른다

정적 애플리케이션 보안검사(SAST)는 프로그램을 실행하지 않고 소스나 코드 표현을 분석하여 보안 결함의 단서를 찾는 검사다. 동적 애플리케이션 보안검사(DAST)는 실행 중인 애플리케이션에 요청을 주고 응답·행동을 관측하는 검사다. 소프트웨어 구성 분석(SCA)은 사용하는 외부 구성요소와 버전·의존성을 식별하고 알려진 취약점 등 관련 정보를 대조하는 분석이다. OWASP의 DevSecOps 지침은 소스 분석, 실행 중 검사와 의존성 분석을 구분한다.[SE-C04]

도구의 방식이 다르다고 결과를 무조건 독립 증거로 곱하지 않는다. 같은 규칙이나 취약점 데이터에 의존할 수 있다. SAST는 항상 정확하고 DAST는 업무 논리를 절대 검사할 수 없다는 식의 비교도 틀리다. 선택한 도구의 지원 범위·설정·도달 경로를 확인하고 남은 질문에 다른 증거를 배치한다.

3. 시험 자체가 사고가 되지 않도록 범위를 고정한다

NIST SP 800-115는 평가 전에 대상·허용 활동·담당·자료 취급·사고 시 조치의 범위와 승인을 정하도록 설명한다. 단일 기법만으로 포괄적인 보안 상태를 확인할 수 없으므로 목적에 맞게 방법을 조합한다. 이 지침은 평가 방법의 근거이며 2008년 문서의 도구 목록을 최신 제품 권고로 사용하지 않는다.[SE-C03]

자체 계획 SE-P1은 가상 공유 서비스의 격리된 시험 환경과 합성 문서 D7만 대상으로 한다. 내부 발급자, U7, 다른 감사자 U8의 시험 계정을 준비하고 운영 고객 문서·다른 회사 시스템·서비스 중단을 유발하는 대량 요청은 제외한다. 시험 담당자는 승인된 환경·소스 및 설정 버전·기간·연락 담당을 기록한다. 실제 운영시험으로 확대하려면 권한과 영향 범위를 별도로 승인받는다.

보안 담당은 대상·기대값과 수집할 증거를 검토하고 개발 담당은 재현·수정을 맡는다. 시험 중 실제 비밀정보가 노출되거나 승인 대상 밖으로 요청이 나가면 중단하고 지정 담당자에게 알린다. 기록에는 요청의 안전한 식별자, 정책·문서 버전, 기대·관측 결과를 남기며 비밀번호·세션 비밀이나 실제 문서 본문을 일반 보고서에 넣지 않는다. 시험 종료 뒤 시험 계정·자료·권한의 제거도 확인한다.

4. 직접 계산: 실시율과 통과율의 분모

자체 결과표 SE-T1은 앞 절의 Q1~Q6을 실제로 관측했다고 가정한 모의 기록이다. Q4는 만료 직전과 경계 두 요청의 묶음이며 두 결과가 모두 맞아야 그 사례를 통과로 센다. 표의 한 행을 평가 사례 한 개로 세고 요청 횟수와 혼동하지 않는다.

계획한 사례는 6개, 실행한 사례는 5개, 통과는 4개다. 실시율은 5/6≈83.33%, 실행 사례 중 통과율은 4/5=80%, 계획 대비 통과 확인 비율은 4/6≈66.67%다. 어떤 분모인지 붙이지 않은 “80% 완료”는 부족하다. 실패 1개와 미실행 1개를 각각 남기고, Q5가 필수 회수 요구를 어기므로 이 상태의 출시를 보류한다.

네 요구 R1~R4에 모두 시험이 연결되어 있더라도 R3는 실패하고 R4는 미확인이다. 시험 계획의 요구 연결률 100%와 요구 검증 완료는 다르다. Q5를 수정한 뒤 다시 통과해도 Q6이 미실행이면 확인된 통과는 5/6일 뿐이고, Q6까지 실행하여 결과를 확인해야 한다. 실제 배포물과 설정이 달라졌으면 영향을 받는 정상·실패 사례도 다시 확인한다.

5. 심각도와 우리 조직의 조치 순서를 구별한다

공통 취약점 평가체계(CVSS)는 취약점의 특성과 심각도를 공통된 지표와 점수로 표현하는 체계다. FIRST의 CVSS v4.0은 기본·위협·환경·보충 지표를 구분한다. 기본점수만을 조직 위험점수로 사용하지 않으며, 실제 위협과 배포 환경의 조건을 더 보아야 한다. 보충 지표는 정보를 제공하지만 최종 점수를 바꾸지 않는다.[SE-C05]

예를 들어 같은 라이브러리 결함이어도 운영 시스템에 실제 포함됐는지, 외부에서 도달하는지, 어떤 데이터와 권한에 영향을 주는지가 다르다. 이 차이를 무시하고 점수 높은 순서로 설치 작업만 배정하면 실제 피해가 진행 중인 자산을 늦출 수 있다. 점수·벡터를 인용할 때는 판본과 지표 구성을 함께 기록하고 서로 다른 점수의 의미를 섞지 않는다.

실제 악용 근거와 미확인을 판단에 반영한다

CISA의 알려진 악용 취약점 목록(KEV)은 실제 악용 근거가 있는 취약점을 우선순위 판단에 활용하도록 제공한다. CISA의 해당 공지는 미국 연방 민간 행정기관에 적용되는 지시와 다른 조직에 대한 권고를 구별한다. 그 기한을 한국의 모든 조직에 같은 법적 의무로 옮기지 않는다.[SE-C06]

목록에 없다는 사실만으로 악용되지 않거나 안전하다고 확정하지 않는다. 취약점 식별자·영향 버전·우리 자산의 실제 포함 여부와 관측을 대조하고 자료의 확인일을 기록한다. 아래 세 항목은 실제 CVE나 계산된 CVSS 수치가 아닌 자체 판단 사례다.

일반 심각도, 실제 노출·악용, 자산 중요도와 조치의 서비스 영향은 서로 다른 입력이다. V2의 임시 차단은 결함 제거가 아니며, V1도 시험 환경의 다른 연결이나 재배포 위험을 다시 확인해야 한다. 예외를 허용하면 대상·기간·보완 통제·책임자·재검토 조건을 명시하고, 미확인을 영구 예외로 바꾸지 않는다.

6. 직접 계산: 설치 7대와 조치 완료 5대

자체 현황 SE-V1은 특정 결함의 영향 자산이 8대로 확정된 한 시점의 표다. 자산 ID별로 한 번 세며, 확인하지 못한 다른 자산이 없다는 가정은 이 교육 표 안에서만 둔다.

설치율은 (5+2)/8=87.5%이고 수정 완료 확인 비율은 5/8=62.5%다. 임시 격리 1대를 포함하여 8/8 수정 완료라고 보고할 수 없다. 설치했지만 확인되지 않은 2대는 실제 실행 버전·필요한 재시작·설정 적용과 재시험을 마쳐야 하고, 격리한 1대는 수정·재시험 및 정상 복귀 조건을 확인해야 한다.

재시험은 해당 결함의 재현 경로가 막혔는지와 정당한 업무가 계속되는지를 함께 확인한다. 운영 담당이 실제 배포 자산·산출물·설정 버전을 확인하고 시험 담당은 결과와 잔여 문제를 연결한다. 설치 명령 성공, 스캐너에서 경고가 사라짐, 네트워크 격리의 세 결과는 서로 다른 증거다. 영향 범위가 새로 늘면 분모와 완료 비율도 다시 계산한다.

7. 개발 흐름에 보안을 붙이는 실제 운영안

NIST SSDF 1.1이 제시한 취약점 감소·영향 완화·근본 원인 대응을 이 사례의 개발·운영 흐름에 적용한다. 한 번의 수정뿐 아니라 같은 실수가 다시 생기는 요구·설계·구현·검사상의 이유를 찾아 개선하는 것이 목적이다.[SE-C07]

근본 원인을 요구·규칙·검사로 환류하여 재발을 줄인다.

SE-G1의 개발자는 Q5 실패 원인을 조사해 회수 확인이 빠진 서버 경로를 고치고, 그 경로와 동등한 다운로드 경로에 회귀 시험을 추가한다. 검토자는 기대값을 바꾸어 실패를 없앤 것이 아닌지 확인한다. 빌드 담당은 소스·구성·산출물 식별자를 연결하고, 배포 담당은 시험한 버전과 실제 배포 버전이 같음을 대조한다. 배포 뒤 설정·실행 상태가 달라지는 문제는 운영 시험으로 찾는다.

사소한 문서 수정마다 모든 도구를 중복 실행하는 대신 변경의 영향에 맞는 검사를 선택하되, 필수 회수·인가 조건을 빠뜨리지 않는다. 검사 실패를 오래 방치하거나 통과선을 내려 출시하지 않는다. 긴급 변경도 승인된 범위·근거·보완 통제·기한과 사후 재시험을 남기며, 복귀 대상의 알려진 결함과 데이터·설정 호환성을 확인한다.

누가 어떤 증거로 종결하는가

업무 책임자는 필수 보호 결과와 서비스 영향을 정하고, 보안 담당은 확인된 위협·노출·악용·예외를 검토한다. 개발 담당은 원인과 수정, 시험 담당은 계획·실행·기대 결과의 대조, 운영 담당은 영향 자산·실제 적용·복귀와 관측을 맡는다. 자기 보고만으로 검토 역할을 생략하지 않고 중요한 결과는 다른 담당의 확인 경로에 남긴다.

SE-T1의 필수 회수 실패나 미실행 장애 시험이 남아 있으면 공유 기능의 출시를 보류한다. SE-V1의 조치는 자산별 수정·실행·재시험·업무 확인이 있어야 완료로 분류하며 예외·격리·진행 중을 별도로 표시한다. 이는 자체 운영 기준이며 실제 기관의 승인이나 교재에 대한 사람의 독립 검수 완료를 뜻하지 않는다.

보고서는 결함 ID·영향 자산·증거·정책/소스/설정 버전·담당·다음 확인 시점을 연결한다. 원인 제거가 어려우면 현재 피해를 제한하는 조치와 남은 위험을 분리해 설명한다. 근거가 부족하다는 사실을 감추려고 ‘해당 없음’으로 바꾸거나 조용히 경고를 제외하지 않는다.

높은 통과율이 가리는 것

가벼운 시험 100개를 더 통과시켜도 Q5의 문서 유출이 사라지지는 않는다. 실패를 재실행하지 않은 채 시험 목록에서 지우면 과거 결과의 의미가 바뀐다. 결함의 적용 여부를 검토하여 오탐으로 종결하는 것과, 이유 없이 경고를 숨기는 것도 구별해야 한다.

수집·검사기가 꺼져 발견이 줄었거나, 격리로 경로가 사라져 스캐너가 접근하지 못한 경우에는 결함이 제거됐다고 쓸 수 없다. 미실행과 확인 불가는 미확인으로 남기고, 영향 자산과 검사 범위를 다시 대조한다. 통과한 결과는 실제 시험한 버전·설정·환경·시점의 범위에만 적용한다.

이 절의 보조 범위

이 절은 요구별 보안 증거를 평가하고 취약점의 우선 조치·수정 완료·개선 조건을 정한다. 대상은 공유 서비스의 시험 사례와 영향 자산·버전·설치·재시험 기록이다. 경계는 실시와 통과, 심각도와 조직 우선순위, 설치·완화와 수정 완료의 구별이다. 필수 실패·미실행·실제 적용 미확인을 종결하지 않고 재시험한다. 모든 공격의 탐지, 특정 제품 적합성, 법정 기한의 보편화나 실제 보안 인증은 제외한다.

8. 자체 10점 문제

SE-T1의 실시율·통과율과 출시 가능 여부를 계산하고, SE-V1의 설치율과 수정 완료 확인 비율이 다른 이유 및 취약점 우선순위 판단 근거를 설명하라.

각 비율의 분자·분모와 판정 범위를 적는다. 시험 사례와 자산을 한 분모로 합치지 않는다. 아래 답안은 자체 교육 예시다.

먼저 Q1~Q6의 수행·통과·실패·미실행을 세고 각 분모를 적는다. 스캐너의 경고가 0개여도 Q5의 철회 실패를 릴리스 차단 조건으로 삼는 이유를 설명한다.

시험: 계획 6 → 실행 5 → 통과 4, 실패 1·미실행 1 → 출시 보류
자산: 영향 8 → 설치 7, 수정·재시험 확인 5 → 완료 5/8
우선순위: 심각도 + 실제 노출·악용 + 자산 영향·조치 비용

9. 자체 25점 문제

한시 문서 공유 기능의 보안검증·취약점 조치 운영안을 설계하라. 검사 방법과 승인 범위, 실패·미실행 처리, 우선순위와 자산별 완료, 개발·배포·운영 환류 및 종결 증거를 포함하라.

도구를 나열하는 대신 각 방법이 확인하는 질문, 사용할 환경·계정·자료, 누구의 어떤 증거로 출시와 종결을 판단하는지 작성한다.

설치한 7대와 재검증까지 완료한 5대를 분리해서 적는다. 격리된 1대를 수정 완료에 합산할 수 있는지도 판단한 뒤 영향 경로 시험과 위험 소유자의 결정을 연결한다.

10. 자기교정

조건을 바꾸어 판단하기

Q5만 수정하여 통과하고 Q6은 그대로라면? 실행 5개가 모두 통과하여 실행한 사례 중 통과율은 100%지만 계획 대비 확인은 5/6이고 Q6은 미확인이다. 결과표에서 분모와 출시 조건을 따로 본다.

진행 중 2대가 실제 재시험까지 통과하면? 완료 확인은 7/8=87.5%이고 격리한 1대는 아직 미완료다. 자산 표의 상태를 근거에 따라 이동한다.

같은 결함의 영향 자산 2대를 추가 발견하면? 기존 완료 5대가 그대로라면 새 분모는 10대로 완료 확인은 50%다. 새 자산의 상태를 조사하고 옛 62.5%를 유지하지 않는다. 종결 기준을 이용해 면접에서는 ‘조치가 진행되어도 비율이 낮아질 수 있는 이유’를 설명한다.

답안을 닫고 분모부터 복원하기

Q5만 고쳐 다시 통과했다고 가정하면 수행률은 5/6 그대로이고, 수행한 시험의 통과율은 5/5로 바뀐다. 전체 계획 대비 통과율은 5/6이며 Q6은 여전히 미실행이다. 필수 Q5의 실패가 해소됐다는 사실과 전체 계획이 끝났다는 결론은 서로 다른 근거를 요구한다. 이어 영향 자산이 8대에서 10대로 늘고 완료는 5대 그대로라면 완료율은 50%다. 분모가 바뀐 계산을 원래 62.5%와 같은 집단의 개선 추세로 해석하지 않는다.

이 두 변경을 원래 표를 보지 않고 계산하고 “설치했으니 닫음”, “수행한 시험이 전부 통과했으니 모든 요구 검증 완료”라는 답의 누락 근거를 각각 한 가지씩 말한다. 이 절의 검증 상태와 릴리스 기준은 자체 사례 조건으로 판단한다.

2026-10-05에 FIRST CVSS v4.0 User Guide와 NIST SSDF 1.1의 공식 범위를 대조했다. CVSS의 기술 심각도와 조직의 위험·처리 우선순위를 동일시하지 않고, Supplemental 지표가 최종 점수를 바꾸지 않는다는 구분을 유지한다. 이 확인은 오늘의 KEV 전체 항목이나 국내 법적 의무를 확인한 것이 아니며 아래의 날짜가 붙은 기존 근거 범위를 유지한다.

근거와 한계

SE-C03은 NIST SP 800-115(2008)의 Executive Summary, §6.5와 Appendix B의 평가 계획·허용 범위·자료 취급·중단과 복수 기법 설명을 사용했다. 해당 PDF 인쇄 ES-1/ES-2·6-10·B-1 페이지를 화면으로 대조했다. SE-C04는 OWASP DevSecOps Guideline v-0.2의 Static Application Security Testing과 Dynamic Application Security Testing의 관측 대상 구분에 한정하며 제품 추천이나 탐지율 주장이 아니다.

SE-C05는 FIRST CVSS v4.0 User Guide의 Overview·Use of CVSS, SE-C06은 CISA의 2025-02-06 KEV 공지에 명시된 실제 악용 근거와 적용 기관·권고 구별을 사용한다. 이 과거 공지를 최신 취약점 목록으로 제공하지 않는다. SE-C07은 기존 SRC-DVO-SSDF11의 NIST SSDF 1.1 Abstract 범위를 적용하며 기존 관찰일은 유지한다. 신규 웹 관찰일 2026-09-19를 발행일이나 한국의 법적 효력일로 바꾸지 않는다.

SE-P1·SE-T1·SE-V1·V1~V3와 모든 표·도식·답안은 자체 교육 자료다. 실제 공격 코드·운영 자격증명이나 실측 CVSS 계산값을 제공하는 예가 아니다. 전권 독립 기술·권리·초보 독자 검수와 실제 조직 승인은 별도다.

회독의 핵심

보안검증은 요구에 맞는 방법과 기대값으로 실제 결과를 확인하는 일이다. 실시·통과·미실행, 심각도·위험, 설치·완화·수정 완료를 구별한다. 수정한 실제 자산과 버전을 재시험하고 정상 업무까지 확인한 뒤 종결하며, 실패 원인을 앞의 요구·설계·개발 흐름으로 되돌린다.