수정 순서와 남는 위험

수정 순서는 결정 기록입니다

보안 담당자는 위협을 많이 찾는 것만으로 일을 끝내지 않습니다. 개발 시간과 서비스 영향을 고려해 먼저 고칠 문제, 잠시 받아들일 위험, 추가 조사할 가정을 구분해야 합니다. 이번 앱에서는 권한 누락의 재발, 자유 입력의 후속 처리, 세션 원문 기록 가능성을 비교합니다. 숫자 하나로 정답을 만든다고 생각하지 않고 왜 그 순서를 택했는지 다른 담당자가 따라갈 수 있게 기록합니다.

앞 모듈에서 이미 고친 소유자 검사를 현재 미수정 결함보다 앞에 다시 배치할 이유가 있는지 묻습니다. 회귀 시험 유지 작업과 새 결함 수정 작업은 상태가 다릅니다. 우선순위 표에는 위협 ID, 현재 상태, 노출, 영향, 실현 조건, 근거, 조치, 담당, 목표 시점, 재검토 계기를 넣습니다. 담당 없이 나중에 처리한다고 적은 항목은 실제 계획으로 이어지기 어렵습니다.

노출과 실현 조건을 읽습니다

노출은 누가 입력 경로에 도달할 수 있는지를 뜻합니다. 익명 로그인 경로와 로그인 후 자료 경로, 파일 권한이 필요한 로컬 로그 경로는 접근 조건이 다릅니다. 실현 조건에는 계정 보유, 유효한 세션, 존재하는 자료 ID, 특정 코드 누락 등이 있습니다. 자료 ID를 알아야 한다는 조건만으로 낮은 위험이라 단정하지 않습니다. ID가 예측 가능하거나 정상 기능에서 보이면 그 조건은 약한 장벽입니다.

영향은 어떤 자료가 얼마나 노출·변경·삭제되고 누구의 업무가 영향을 받는지 설명합니다. 실습 계정 수가 적다고 설계 결함이 중요하지 않은 것은 아닙니다. 합성 데이터의 피해와 실제 서비스 전환 시 예상 피해를 나눠 적습니다. 지금 로컬 함수 검사에서 확인한 범위와 공개 배포를 가정한 범위를 섞으면 위험 수치가 과장되거나 축소됩니다.

비교 예시를 현재 상태에 맞춥니다

T-owner는 앞 수정으로 통제되었으며 회귀 시험 유지가 조치입니다. T-change는 변경 전 인가와 거절 후 원본 보존을 재확인합니다. T-login은 원문 로그 미수집을 유지하고 향후 공개 노출 전에 속도 제한과 전송 보호를 검토합니다. 새로운 로그 기능이 세션 원문을 기록한다면 그때는 유효 세션을 그대로 재사용할 조건을 조사하여 우선 수정 후보로 올립니다. 존재하지 않는 로그 유출을 이미 발생한 사고라고 쓰지 않습니다.

자유 입력은 어떤 문맥으로 저장·조회·렌더되는지 확인해야 합니다. 본문을 문자열로 보관한다는 사실만으로 SQL 주입이나 스크립트 실행을 확정하지 않습니다. 저장 질의 구성과 출력 문맥이 생기는 다음 모듈에 확인 항목을 넘깁니다. 미확인 항목에는 조사 담당과 확인할 코드 경로를 적고 정보 부족 때문에 우선순위를 잠정이라고 표시합니다.

점수는 비교 보조입니다

실습용으로 영향과 노출을 각 1부터 3까지 평가하고 곱을 정렬 기준으로 쓸 수 있습니다. 이 값은 발생 확률이나 공식 취약점 등급이 아닙니다. 같은 점수일 때 더 쉽게 도달하는 경로, 피해 범위, 기존 통제 증거를 읽어 순서를 결정합니다. 평가 범위와 숫자의 뜻을 먼저 정의하지 않으면 담당자마다 같은 값이 다른 의미를 갖습니다. 따라서 최종 표에는 숫자뿐 아니라 근거 문장이 필요합니다.

빠르게 고칠 수 있다는 이유만으로 큰 영향의 미수정 문제를 계속 미루지 않습니다. 임시로 입력 경로를 닫거나 해당 기능을 제한할 수 있으면 영구 수정과 별도 조치로 적습니다. 조치 후 정상 사용자 기능을 확인하고 되돌림 방법을 남깁니다. 이번 레슨은 위험 수용을 임의로 승인하는 실습이 아니라 검토 요청에 필요한 판단 근거를 쓰는 실습입니다.

잔여 위험에는 주인이 필요합니다

통제 후에도 남는 조건을 잔여 위험이라고 기록합니다. 소유자 검사가 있어도 이미 탈취된 소유자 세션으로 접근하면 서버는 정상 소유자로 볼 수 있습니다. 그래서 세션 보호와 폐기, 접근 관찰이 다른 통제로 필요합니다. 이 앱의 메모리 저장과 동기 KDF, HTTP 전송, 계정 삭제 기능 부재는 테스트 통과로 사라지지 않습니다. 남은 조건을 구체적으로 적으면 다음 모듈에 인계할 작업이 명확해집니다.

수용 제안에는 범위, 기간, 책임자, 재검토 조건을 씁니다. 예를 들어 로컬 합성 자료 환경에서만 전송 보호 미구현을 허용하고 외부 공개 전에 다시 검토한다고 적습니다. 실제 운영의 승인권자는 조직 정책에 따라 따로 확인해야 합니다. 공개 서비스의 위험을 학습자가 혼자 수용했다고 선언하지 않습니다. 새로운 백업이나 관리자 기능이 생기면 삭제 범위와 권한 모델도 다시 읽습니다.

미션 완료와 인계

이번 미션 starter에는 앞 solution의 앱과 보고서가 들어 있으며 threat-model.json의 지정 미완성 항목만 채웁니다. python3 verify-model.py로 연결 계약을 검사하고 python3 model-tests.py로 잘못된 자산·경계·검증 누락·빈 문장·흐름 누락의 거절을 확인합니다. bash threat-check.sh는 이 검사와 앞 identity-check.sh를 묶습니다. 전체 bash check.sh는 앞 컨테이너 권한·HTTP 경계를 이어서 검증하므로 샌드박스 밖 실행 대기입니다.

AssertionError: reject 메시지는 잘못된 모델을 검사기가 받아들였다는 뜻이고 ValueError의 위협 ID와 필드는 작성한 연결이 틀렸다는 뜻입니다. 기대값을 낮추거나 검사 파일을 지우지 않습니다. 제출 보고서는 우선순위 이유와 미검증 범위를 명시합니다. 자동 검사 통과 뒤 각 위협의 검증 문장이 실제 시험과 대응하는지 사람이 읽고, Docker 대기는 로컬 통과와 다른 상태로 인계합니다.

실무 리뷰를 한 번 더 합니다

우선순위 회의에서는 반대 의견을 기록할 수 있어야 합니다. 개발 담당자가 특정 조치로 정상 로그인 실패가 늘 수 있다고 말하면 기능 시험과 단계적 적용 조건을 추가합니다. 보안 담당자는 위험 감소 근거를 제시하고 제품 담당자는 허용 범위를 확인합니다. 이 교재에서는 가상의 담당 역할을 적되 실제 조직 승인을 받았다고 쓰지 않습니다. 합의가 필요한 항목은 결정 대기로 두고 다음 확인 자료와 목표 시점을 남깁니다.