보고서와 수정 요청 인계
65분 안팎
학습 목표
영향·우선순위·담당·잔여 위험을 전달합니다.
개념
인계는 다음 행동을 가능하게 합니다
최종 보안 점검 보고서는 많이 검사했다는 증명서보다 다음 담당자가 같은 근거로 판단하고 수정할 수 있는 작업 문서입니다. 영향이 큰데 담당이 없으면 요청이 멈추고, 테스트가 통과했는데 조건이 없으면 재현할 수 없습니다. 이번 레슨은 E01부터 E09까지의 기록과 T10 가상 대응을 하나의 색인으로 연결합니다. 새 보고서에는 허가 범위·재현 조건·영향·수정안·재검증과 타임라인·격리·복구·잔여 위험을 함께 담습니다.
과거 기록과 현재 상태
report.md의 E01에는 메모리 저장이 기록돼 있지만 현재 앱은 SQLite 자료와 메모리 세션을 사용합니다. 과거 문장을 현재 상태로 몰래 고쳐 쓰면 당시 증거의 의미가 바뀝니다. 과거 결과는 그 시점의 관찰로 보존하고 response-report.json을 현재 통합 보고서로 만듭니다. index에는 모듈·근거 파일·의미를 적어 독자가 과거 기록과 새 검증을 구분합니다. 링크가 있다는 사실만으로 해당 모듈의 모든 운영 검증이 끝났다고 주장하지 않습니다.
봉인된 파일을 조용히 갱신하지 않습니다
m08 manifest에는 auth.cjs와 secure-app.cjs의 해시도 있습니다. 격리 기능을 추가하면 현재 파일은 그 목록과 달라지는 것이 정상입니다. 기존 해시를 새 코드에 맞춰 덮어쓰는 대신 prior-m09 폴더에 앞 모듈 solution을 보존합니다. 그 사본의 manifest 검사는 이전 근거에 대해 수행하고 새 코드는 새 회귀 테스트로 확인합니다. 같은 파일 이름이더라도 검증 시점이 다르면 다른 산출물이라는 사실을 인계에 명시합니다.
요약에는 관찰한 영향만 씁니다
F-owner 취약 fixture에서는 타인 자료 조회 200을 관찰했고 수정 앱은 404입니다. 그 영향은 그 로컬 조건에 대한 결과입니다. 가상 경보 d1은 접근 거절이므로 유출 입증이라고 쓰지 않습니다. 입력 결함과 의존성 가상 공지도 실제 사고 증거로 바꾸지 않습니다. 요약은 관찰한 결과, 가능한 위험, 아직 모르는 범위를 문장으로 나눕니다. 수치와 상태를 과장하지 않으면 비개발 담당자도 무엇이 확인됐는지 읽을 수 있습니다.
수정 요청의 최소 계약
개발 요청에는 어떤 조건에서 무엇이 잘못되는지, 사용자가 받는 영향, 바꿀 정책, 정상 경로와 거절 경로의 완료 기준을 적습니다. 담당과 기한 또는 재검토 시점을 함께 전달합니다. R10은 격리 상태 영속화와 다중 인스턴스 전파를 대상으로 합니다. 완료 기준은 재시작 후에도 옛 세션과 차단 계정 신규 로그인이 거절되고 정상 계정은 영향 범위대로 동작하는 시험입니다. 수정 담당자가 추가 질문 없이 테스트를 설계할 수 있는지 읽어 봅니다.
우선순위는 이유와 함께 둡니다
외부 공개 전 차단 상태 지속성을 확인해야 하는 이유는 현재 메모리 구현이 재시작 때 정책을 잃기 때문입니다. 단순히 높은 위험이라고 적는 것보다 영향 조건을 설명하면 우선순위가 이해됩니다. 조사 공백 m1은 코드 수정 요청과 다른 작업이며 security-team의 추가 로그 확인으로 분리합니다. 어떤 요청이 대응을 막고 어떤 요청이 다음 검토까지 가능한지 정할 때 현재 허가 범위와 사용 환경을 기준으로 판단합니다. 모든 요청을 같은 긴급도로 쓰지 않습니다.
보고서 구조 검사와 내용 검토
response-report-check.py는 필수 설명의 존재와 길이, 사건 id 연결, 시간 원본 일치, 격리 순서, 복구 문턱, 모듈 색인, 잔여 위험의 담당·기한·완료 기준을 확인합니다. 이 검사는 엉뚱한 문장이 길게 들어가도 의미까지 이해하지 못합니다. rubric의 사람 검토가 필요한 이유입니다. 동료는 근거 파일을 열고 영향 문장이 실제 관찰을 넘지 않는지, 해당 담당자가 실행 가능한 요청인지 교차 검토합니다. 자동 통과는 문서 품질 전체의 인증이 아닙니다.
외부 대기를 숨기지 않습니다
legacy-check.sh는 Docker의 비루트 사용자·network none·포트 게시와 마운트 없음 및 이전 권한·HTTP 회귀를 확인하는 별도 경로입니다. 이번 샌드박스에서는 실행하지 않으므로 external PENDING입니다. 로컬 check.sh 성공 행에 이 검사의 완료를 섞지 않습니다. 소켓·TLS·실제 브라우저도 미검증으로 적습니다. 검토자가 운영 적용 여부를 판단하려면 검사 이름과 범위, 실행 여부, 후속 담당을 한눈에 확인할 수 있어야 합니다.
개발팀과 조사팀의 전달 범위
개발팀에는 최소 재현 조건과 기대 정책, 회귀 시험을 전달합니다. 조사팀에는 사건 id와 결측, 시각 불확실성, 추가 확인할 로그 출처를 전달합니다. 보고서 독자에게 실제 세션 토큰이나 자료 본문은 필요하지 않습니다. 원문 보관이 필요한 사건이라면 접근 제한된 증거 위치를 참조하고 일반 수정 요청에는 최소한의 합성 재현 입력을 씁니다. 이번 산출물은 합성 자료이지만 인계에서도 민감 필드를 불필요하게 늘리지 않는 습관을 유지합니다.
잔여 위험을 관리 가능한 항목으로
잔여 위험에는 문제가 남았다는 문장만 적지 않습니다. 담당 app-team 또는 security-team, 외부 공개 전 또는 재검토 전 같은 시점, 무엇을 확인하면 닫을지 완료 조건을 적습니다. 수집 결측은 추가 로그를 확보하거나 미확인 범위를 명시하는 기준으로 관리합니다. 키 전달과 세션 지속성은 설계·시험의 후속입니다. 독자가 파일을 받은 뒤 무엇을 할지 정할 수 없다면 항목을 더 작게 나누거나 담당을 구체적으로 지정합니다.
대응 회고의 초점
회고는 누가 잘못했는지 찾기보다 판단을 늦춘 정보와 절차를 찾습니다. 이번 훈련은 결측 때문에 침해 여부를 판정할 수 없었고 계정 매핑도 가정이었습니다. 다음 훈련에서 수집 지연·누락 시험과 계정 매핑 확인 절차를 추가한다는 개선안을 적습니다. 자료 복구 성공과 조사 종료는 같은 상태가 아닙니다. 대응 조치를 완료했어도 유출 여부가 미확인이면 그 질문과 다음 확인 책임을 열어 둡니다.
실행 가능한 인계로 마칩니다
최종 ZIP을 새 폴더에 풀고 bash check.sh를 실행한 뒤 종료 코드와 검사 요약을 기록합니다. solution 성공과 starter 지정 실패를 각각 확인해 검사 자체가 살아 있는지 봅니다. response-report.json과 handoff.md를 색인에서 찾아 담당·기한·미확인 항목을 읽습니다. 서재 관측 장에서는 로그 설계를 더 공부하고 이 레슨에서는 증거가 어떤 주장까지 뒷받침하는지를 설명합니다. 인계자는 성공 항목과 대기 항목을 함께 전달해 후속 검토가 이어지게 합니다.
따라하기
모듈 색인 누락 찾기
파일 이름만 나열하지 말고 전체 모듈 색인의 빠진 연결을 찾습니다.
actual={'m%02d'%i for i in range(1,10)}
required={'m%02d'%i for i in range(1,11)}
print(','.join(sorted(required-actual)))실행 결과
m10
인계 문턱의 대기 상태
로컬 성공을 외부 미실행 항목의 성공으로 확장하지 않습니다. 상태마다 근거와 담당을 추가합니다.
checks={'local':'PASS','docker':'PENDING','tls':'NOT_TESTED'}
for name,status in checks.items():
print(name,status)
print('all_verified',all(s=='PASS' for s in checks.values()))실행 결과
local PASS docker PENDING tls NOT_TESTED all_verified False
실행 가능한 수정 요청 읽기
담당·시점·완료 기준을 갖췄는지 확인합니다. 문장 의미가 실제 근거와 맞는지는 사람 검토로 보완합니다.
request={'owner':'app-team','due':'before-public','acceptance':'restart-denies-old-session'}
print(all(request.get(k) for k in ['owner','due','acceptance']))
print(request['acceptance'])실행 결과
True restart-denies-old-session
확인 문제
실습
미션 ZIP의 response-report.json과 handoff.md를 제출합니다. m01~m10 색인·허가 범위·조건·영향·수정·재검증·사건 타임라인·격리 순서·복구 문턱·담당과 기한 및 잔여 위험을 포함합니다. 동료는 최소 세 근거 파일을 열어 관찰과 추측을 교차 확인합니다. 개발 요청 한 건에 조건·기대 정책·정상/거절 시험·담당·시점을 쓰고, 회고 한 건에 정보 공백과 다음 훈련 개선을 씁니다. 문서 검사는 bash check.sh에 포함되며 의미 검토는 rubric으로 수행합니다.
더 읽기
면접 질문
- 보안 점검의 허가 범위를 확인하는 절차를 설명합니다.
- 취약점 수정 전후의 테스트 내용을 설명합니다.