보안 점검
한 가지 질문에 잘 답하세요: 이 프로젝트가 지금 당장 중요한 종속성 취약점에 노출되어 있습니까? '지금 당장 중요하다'는 것은 목록에 등록되어 있고 접근 가능하거나, 아직 감사 데이터베이스에 완전히 전파되지 않은 활성 사고를 의미합니다.
단순한 npm audit보다 가치 있는 점은 조사 레이어입니다. 권고 데이터베이스는 공개보다 늦게 업데이트되며, 악성 패키지 사고는 종종 게시를 취소하여 처리됩니다(조회 가능한 권고가 없음). 따라서 이 점검은 결정론적 도구와 현재 활발히 악용되고 있는 것에 대한 실시간 조사를 결합하고, 해당 이름에 대해 잠금 파일을 직접 확인합니다. 이는 가장 빠르고 신뢰할 수 있는 신호로, 어떤 감사 도구도 제공하지 않습니다.
기본적으로 읽기 전용입니다. 조사하고 보고합니다. 수정 사항을 제안만 하세요. 사용자의 동의 없이 버전을 올리지 마십시오(빌드가 손상될 수 있음).
사용 시기
- '보안 조사' / '취약한 종속성 확인' / '보안 점검 실행'.
- '우리가 <특정 CVE, GHSA 또는 패키지 손상 사례>에 영향받나요?' — 사용자가 무언가를 읽고 자신의 노출 여부를 알고 싶어함.
- 정기적인 확인(schedule 스킬과 결합하여 반복 클라우드 점검 — 끝 부분 참조).
1단계 — 범위
무엇을 점검할지 결정합니다. 기본값은 현재 프로젝트입니다. 사용자의 표현이 광범위한 경우('우리 프로젝트', '모든 것', '전체') 다중 저장소 점검을 제안합니다.
- 현재 프로젝트: 현재 위치한 저장소.
- 다중 저장소: 현재 저장소 옆에 있는 형제 저장소를 열거합니다. 즉, 현재 git 루트의 상위 디렉터리(일반적으로
~/projects/*/또는~/src/*/). 디렉터리를 탐색하기 전에 사용자와 확인하십시오. 잘못된 추측은 긴 스캔 시간을 낭비합니다. 각 저장소에 대해 매니페스트(아래)로 에코시스템을 감지하고, 차례로 점검한 후 프로젝트별로 보고합니다.
2단계 — 에코시스템 감지 및 잠금 파일 찾기
프로젝트별로, 다음 잠금 파일이 있으면 에코시스템이 존재합니다.
| 에코시스템 | 매니페스트 / 잠금 파일 | 일반적인 위치 |
|---|---|---|
| npm | package-lock.json | frontend/ 또는 저장소 루트 |
| Go | go.mod / go.sum | backend/ 또는 저장소 루트 |
| Python | poetry.lock, requirements.txt, uv.lock | 저장소 루트 |
| Swift/SPM | Package.resolved | ios/ 또는 .xcodeproj |
매니페스트가 아닌 잠금 파일을 스캔합니다. 실제 설치된 정확한 전이 버전을 고정합니다.
3단계 — 결정론적 기준선(에코시스템별)
에코시스템 자체 도구를 실행합니다. 이는 이미 권고 데이터베이스에 있는 모든 것을 포착합니다. 가능한 경우 도달 가능성 분석(코드가 실제로 도달할 수 있는 취약점만 보고)이 있는 도구를 선호합니다.
- npm:
cd <dir> && npm audit --omit=dev --audit-level=high(사용자에게 제공되는 것) 및 일반npm audit(모든 정보). 도달 가능성 없음 — 과대 보고; 프로덕션 결과에 가중치 부여. - Go:
govulncheck ./...— 도달 가능성 분석 수행(호출된 코드의 취약점만 플래그 지정);go install golang.org/x/vuln/cmd/govulncheck@latest로 한 번 설치. 이 도구들의 표준. - Python:
pip-audit(또는pip-audit -r requirements.txt). - 모든 에코시스템 또는 도구가 없는 경우: 잠금 파일에 대해
osv-scanner를 컨테이너를 통해 실행하여 설치할 필요가 없음:<runtime> run --rm -v "$PWD:/src:ro" ghcr.io/google/osv-scanner:latest scan --lockfile=/src/<lockfile>.
각 도구가 보고하는 내용을 캡처합니다. 프로덕션/도달 가능과 개발/빌드 시간을 구분하십시오. 빌드 도구의 높은 심각도는 런타임 종속성의 동일한 발견과 같지 않습니다.
4단계 — 활성 위협 환경 조사(부가 가치)
이것이 순수 감사가 할 수 없는 부분입니다. WebSearch/WebFetch를 사용하여 현재 활성화된 것을 찾은 후 5단계로 이름을 가져옵니다.
- 프로젝트 에코시스템의 최근 공급망 사고: 최근 npm/PyPI/Go 손상 및 멀웨어 캠페인 검색; 2단계에서 본 패키지와 관련된 최근 게시 항목을 위해 GitHub Advisory Database(github.com/advisories) 및 OSV(osv.dev) 확인.
- 사용자가 특정 CVE/GHSA/사고를 명명한 경우, 공식 권고를 가져와 정확한 영향을 받는 패키지 이름 및 버전 범위를 추출합니다. 이를 잠금 파일과 대조합니다.
- 1차 출처(권고, 유지관리자의 게시물, 레지스트리의 보안 공지)를 집계 헤드라인보다 선호합니다. 확인되지 않은 사항이 있을 경우 기록하십시오.
최신 상태를 유지하십시오. 모든 주장에 날짜를 표시하고 조사 기간을 명시하십시오(예: '지난 약 8주 동안 공개된 활성 사고').
5단계 — 잠금 파일에서 이름을 직접 대조 확인
4단계에서 발견된 모든 패키지에 대해 감사 도구를 기다리지 말고 직접 고정된 트리를 확인하십시오. 이것이 선행 지표 단계입니다.
# npm
cd <dir> && npm ls <package>
grep -n '"<package>"' package-lock.json
# Go
grep -n '<module-path>' go.sum
# Python
grep -in '<package>' poetry.lock requirements.txt uv.lock 2>/dev/null
# Swift
grep -rn '<package>' --include=Package.resolved .
그런 다음 고정된 버전을 권고의 영향 범위와 비교합니다. 이름당 세 가지 결과: 노출됨(존재하고 범위 내), 안전함(없음, 또는 존재하지만 범위 밖), 불확실(완전히 해결할 수 없는 전이 버전 — 추가 조사 또는 플래그 지정).
6단계 — 보고
프로젝트별로, 평결로 시작하고 증거를 제시합니다.
- 노출됨 — 패키지, 고정 버전, 권고/사고, 프로덕션에서 도달 가능한지 여부, 구체적인 수정 방법(대상 버전 업데이트, 절대 맹목적인
npm audit fix아님). 손상된 버전이 설치되었을 수 있는 경우, 설치 후 스크립트가 이미 실행되었을 수 있음을 기록하십시오 — 이것이ignore-scripts기본값이 중요한 가장 큰 이유입니다. - 안전함 — 확인한 활성 위협이 존재하지 않음. 무엇을 확인했는지 명시하여 '안전함'이 의미를 갖도록 하십시오.
- 불확실 / 미적용 — 도구가 부족한 에코시스템(Swift), 해결되지 않은 전이 종속성, 또는 범위를 확인할 수 없는 조사. 완전한 적용을 암시하지 말고 격차를 명시하십시오.
모든 것을 발견했다고 암시하지 마십시오. 점검 기간과 실제로 점검한 에코시스템을 명시하십시오.
구성
- 반복 점검: 이 스킬의 절차를
schedule스킬에 전달하여 저장소 전체에 대해 주간 클라우드 실행을 수행하여 새로운 사고가 며칠 내에 포착되도록 하십시오. - 릴리스 또는 푸시 전: 범위가 지정된 단일 프로젝트 점검을 실행합니다. 프로젝트에
make audit/make secret-scan사전 푸시 단계가 있는 경우 자연스럽게 연결됩니다.
참고 사항
- 감사 도구는 지연 지표입니다. 뉴스와 이 스킬의 4단계가 선행 지표입니다. 이들 간에 불일치가 있는 경우(조사에서는 패키지가 손상되었다고 하지만 도구는 조용함), 직접 잠금 파일 확인을 신뢰하고 활성 상태로 처리하십시오.
npm audit은 권고 심각도를 보고하지만 사용자의 악용 가능성은 보고하지 않습니다(도달 가능성 분석 없음) — 과대 보고합니다.govulncheck는 반대이며, 에코시스템에서 제공하는 경우 선호하는 모델입니다.- 이 스킬은 노출 여부를 답합니다. 수정(버전 업데이트, 고정, 범위 제외 스크립트 처리를 위한
npm rebuild)은 별도의 사용자 승인 단계입니다. 수정 사항을 제시하되, 요청 없이 적용하지 마십시오.