보안 점검 일정 잡기 - 취약점 점검 창과 스프린트 버퍼 맞추기

보안 점검은 종류를 왜 먼저 갈라야 할까?

코드 진단, 인프라 취약점, 모의 해킹은 준비물과 소요 주수가 다릅니다. 한 칸에 보안 점검이라고만 적으면 일정이 비어 있는 것과 같습니다.

WBS에 보안 점검 1줄만 있으면, 수행은 도구 스캔 하루로 읽고 발주는 모의 해킹 2주로 읽습니다. 종류를 나눕니다.

정적, 동적 코드 진단, 인프라, 웹 모의 해킹, 개인정보 영향. 각 줄에 주관 기관, 예상 주수, 대상 환경이 필요합니다.

종류가 갈리면 선행 산출물도 갈리고, 한 줄이면 오픈 직전에야 무엇이 빠졌는지 드러납니다.

점검 전에 어떤 산출물이 준비돼야 할까?

계정, 네트워크 구간, 시험 데이터, 고정된 빌드 번호가 있어야 점검이 시작됩니다. 화면만 있으면 점검 창이 공칩니다.

점검 주가 됐는데 관리자 계정이 없거나, 외부에서 못 들어오거나, 데이터가 비어 있으면 그 주는 대기 주입니다. 착수 때 점검 종류별 선행 목록을 표로 두고, 준비 완료일을 오픈일에서 역산합니다.

Risk(위험)에 선행 미비를 올리면 개발 막바지에 계정 발급이 이슈가 아니라 일정 위험이 됩니다. 선행이 끝난 뒤에야 점검 창을 연다고 적으면, 스프린트 마지막 날 몰아넣기를 줄일 수 있습니다.

재점검 창은 왜 첫 점검만큼 중요한가?

첫 점검에서 나온 조치는 재점검 없이 닫히지 않습니다. 조치 주수와 재점검 주수를 한 쌍으로 잡습니다.

취약점 보고서가 나오면 개발은 고치고, 점검 기관은 다시 확인합니다. 재확인 일정이 없으면 고친 코드가 오픈에 실리고 증빙은 나중에 오겠습니다.

일정표에 첫 점검, 조치, 재점검을 세 칸으로 두고, 치명, 고위험은 재점검 합격을 오픈 조건에 올립니다. 중위험 이하는 오픈 후 N일 안으로 미루더라도 기한을 적습니다.

기한 없는 미룸은 잊힌 취약점입니다.

애자일 스프린트와 보안 창은 어떻게 맞출까?

점검 창은 스프린트 백로그가 옮기지 못하는 외부 날짜입니다. 창을 에픽 바깥 마일스톤으로 고정합니다.

애자일 팀은 스프린트마다 범위를 조정하지만, 외부 점검 기관의 창은 예약제입니다. 예약일을 백로그 우선순위로 밀면 창을 놓치고, 다음 창은 몇 주 뒤입니다.

그래서 점검 창을 로드맵 마일스톤으로 박고, 그 전 스프린트의 완료 정의를 점검 가능 빌드로 둡니다. 기능 스토리가 남아 있어도 점검 대상 범위는 동결합니다.

동결 없는 점검은 움직이는 과녁을 쏘는 것과 같습니다.

일정 버퍼는 어디에 얼마나 둘까?

조치와 재점검 사이에 근무일 버퍼를 둡니다. 버퍼를 기능 개발에 쓰면 오픈일이 취약점 회의로 바뀝니다.

경험상 치명, 고위험 조치에 걸리는 시간은 보고서 장수보다 환경 제약에 비례합니다. 버퍼를 점검 뒤 5~10근무일처럼 숫자로 박고, 그 칸을 기능 백로그가 침범하지 못하게 잠급니다.

버퍼를 기능에 쓰면 재점검이 오픈 전날로 밀리고, 전날 재점검은 조건부 오픈 문장만 남깁니다. 조건부 오픈의 조건 기한을 같이 안 적으면 조건은 구호가 됩니다.