영향과 수정안 전달

finding은 다음 행동을 가능하게 합니다

수정 담당자는 취약점 이름만으로 어디를 어떻게 고칠지 결정하기 어렵습니다. finding은 확인한 조건, 제한된 영향, 수정 위치, 재검증 결과를 하나의 식별자로 묶은 기록입니다. 이번에는 findings.json의 F-owner·F-input·F-secret을 검토합니다. 각각 과거 E04·E06·E07을 가리키며 현재 scope-008과 실행 증거를 연결합니다. 과거 기록을 지우지 않고 이번 확인의 범위를 덧붙입니다.

관찰과 추정을 문장으로 나눕니다

F-owner의 관찰은 인증된 Bob이 Alice 합성 자료를 취약 fixture에서 200으로 조회했다는 것입니다. 그 조건에서 자료 기밀성 통제가 누락된다는 판단을 내릴 수 있습니다. 실제 외부 사용자가 운영 자료를 가져갔다고 쓰면 증거보다 큰 주장입니다. 사고 발생 여부는 별도 로그와 조사 근거가 필요합니다. 보고서에는 직접 본 결과와 해당 조건에서 가능한 영향, 확인하지 않은 사항을 분리합니다.

영향은 대상과 범위를 포함합니다

모든 자료 유출이라는 문구 대신 같은 앱의 다른 회원이 소유한 합성 자료 한 건을 읽은 조건을 적습니다. 읽기와 변경·삭제는 서로 다른 영향이며 조회 재현으로 변경까지 성공했다고 결론내리지 않습니다. 이전 인가 회귀가 타인 PATCH·DELETE를 거절하는 결과는 별도 근거입니다. 재현 가능한 최대 범위를 아직 확인하지 않았다면 그 한계와 필요한 후속 검사를 기록합니다.

수정안은 통제 위치를 가리킵니다

로그인 확인 강화라는 표현만으로는 소유자 인가 누락을 해결하지 못합니다. F-owner는 app.cjs canAccess가 서버 세션의 user.id와 저장 자료의 owner를 비교하고 관리자 읽기 예외만 허용하는 위치를 가리킵니다. 요청 body의 owner를 신뢰하지 않습니다. 수정 담당자는 파일과 검사 케이스를 함께 찾을 수 있어야 합니다. 변경안을 너무 넓게 쓰면 정상 기능을 막는 패치가 들어가기 쉽습니다.

재검증 근거를 구체적으로 붙입니다

retest에는 regression-pair.cjs의 foreign_read_denied와 pair.json의 before·after를 적습니다. 타인 200의 지정 실패, 수정 후 타인 404, 소유자 200, 무인증 401, 없는 자료 404, 원본 보존을 함께 설명합니다. PASS 한 단어만 남기면 무엇을 확인했는지 알 수 없습니다. 실행 명령과 종료 상태, 증거 상대 경로, 해시 목록을 연결하면 검토자가 같은 주장을 다시 확인할 수 있습니다.

누적 결함의 현재 상태를 구별합니다

F-input과 F-secret은 이번 취약 fixture에서 다시 재현한 결과가 아닙니다. 이전 E06·E07의 조건과 영향 기록을 연결하고 previous-check.sh가 현재 수정 앱 회귀를 다시 실행한 결과를 적습니다. F-owner만 이번 동일 짝 비교입니다. 세 finding이 pair.json을 공유해도 그 파일이 모든 결함의 수정 전 결과를 담는다고 쓰지 않습니다. 근거 파일이 있다는 사실과 그 파일이 주장을 지지한다는 판단은 다릅니다.

상태명에 범위를 넣습니다

verified-local은 이번 함수·어댑터 및 임시 저장소 검사에 한정한 확인 상태입니다. 전체 서비스 안전 인증이 아닙니다. Docker 계정·파일 권한과 실제 소켓·브라우저·TLS는 이 상태에 포함하지 않습니다. 외부 검사는 PENDING으로 남깁니다. 가상 의존성 공지는 실제 CVE 확인이나 설치 교체 성공이 아니므로 dependency-review.json의 적용 조건과 계획을 그대로 구분해 전달합니다.

우선순위와 잔여 위험

조치 순서는 영향받는 자료, 필요한 권한, 접근 가능 조건, 현재 통제와 업무 영향을 보고 논의합니다. 근거 없이 점수만 붙이면 수정 담당자가 순서를 검토하기 어렵습니다. 이번 문서에서는 소유자 통제 유지와 정상 업무 회귀를 우선 확인하고 공개 전 HTTP 전송·세션 저장·속도 제한 검토가 남았음을 적습니다. 위험이 남아 있다는 문장은 해결 책임과 다음 확인 조건이 있어야 행동으로 이어집니다.

자동 검사가 보장하는 것

verify-delivery.py는 필수 문장 필드, 이전 근거 식별자, 파일 존재, 범위 연결과 해시를 확인합니다. 문장이 충분한 길이라고 사실이 정확한 것은 아닙니다. 사람이 조건과 결과가 서로 맞는지, 영향이 과장되지 않았는지 읽어야 합니다. starter는 F-owner impact가 비어 있어 실패합니다. 실제 관찰을 바탕으로 영향과 한계를 작성하고 최초 manifest를 확정한 뒤 전체 검사를 실행합니다.

보고서 인계 절차

검토자에게 findings.json·report.md·manifest.json과 상대 경로 증거를 함께 전달합니다. 담당자는 local-learner이며 변경 후 재검증 책임을 적습니다. 실제 팀에서는 수신자, 확인 기한, 재검토 조건을 작업 항목과 연결합니다. 어떤 검사가 아직 대기인지 눈에 띄게 남기면 다음 담당자가 같은 성공 로그를 반복 수집하는 대신 미검증 범위를 조사할 수 있습니다. 실제 비밀 원문은 인계물에 넣지 않습니다.

완료 전 마지막 대조

최종 보고서를 읽으며 각 영향 문장이 어떤 관찰에서 나왔는지 역으로 찾아봅니다. F-owner는 짝 결과, F-input은 입력·질의·출력·CSRF 회귀, F-secret은 설정·키 교체·로그 허용 목록 근거를 확인합니다. 해시는 전달물의 바이트 확인이고 보고서 판단의 품질은 별도 검토입니다. 더 읽기의 운영 보안 장에서는 의존성·실행 권한·민감 로그를 더 넓은 운영 맥락에서 연결합니다.

보고서 문장을 소리 내어 읽고 담당자가 바로 수행할 행동을 찾습니다. “보안을 강화한다”만 있으면 변경 위치와 성공 기준을 알 수 없습니다. “소유자 비교를 유지하고 같은 Bob 조회 404와 Alice 조회 200을 확인한다”처럼 구현과 검사를 연결합니다. 불확실한 영향은 확인할 자료와 담당자를 적습니다. 기계 검사의 성공 뒤에도 주장과 증거의 관계를 읽는 이유는 이 연결이 문자열 길이로 판정되지 않기 때문입니다.