풀 리퀘스트 댓글
GitHub의 모든 풀 리퀘스트에, 알려진 보안 권고가 있는 의존성을 모두 나열한 댓글을 하나 받으세요. Deep 기능이며, 직접 켜기 전까지는 꺼져 있습니다.
풀 리퀘스트 댓글은 잠금 파일에 있는 의존성 버전 중 어떤 것에 알려진 보안 권고가 있는지 풀 리퀘스트 안에서 팀에게 알려 주며, 변경이 추가한 것부터 보여 줍니다. Deep 기능이며, 직접 켜기 전까지는 꺼져 있습니다.
하는 일
풀 리퀘스트가 열리거나, 새 커밋이 추가되거나, 다시 열리면 Lockpick은 잠금 파일을 두 지점에서 읽습니다. 풀 리퀘스트의 head와, 그 브랜치가 기본 브랜치에서 갈라진 지점(머지 베이스)입니다. 두 지점의 정확한 버전을 알려진 보안 권고와 대조합니다.
이 검사는 결정적입니다. 어떤 코드도 실행되지 않고, AI가 검토하지도 않습니다.
Lockpick은 두 목록을 비교하므로, 풀 리퀘스트가 추가하거나 바꾼 것과 이미 있던 것을 구분할 수 있습니다. 브랜치를 만든 뒤 기본 브랜치에 들어온 문제는 그 풀 리퀘스트의 것으로 세지 않습니다.
저장소에 있는 모든 잠금 파일, 또는 내가 고른 잠금 파일을 읽습니다. 잠금 파일은 각각 따로 검사하므로, 모노레포의 Go 모듈과 JavaScript 프로젝트가 모두 포함됩니다. 풀 리퀘스트가 바꾸지 않은 잠금 파일은, Lockpick이 그 파일을 이미 그대로 읽었다면 다시 내려받지 않습니다.
지원하는 잠금 파일
잠금 파일이 고정한 정확한 버전만 읽습니다. 아무것도 해석하거나, 설치하거나, 실행하지 않습니다.
| 스택 | 잠금 파일 | 권고 출처 |
|---|---|---|
| JavaScript와 TypeScript | pnpm-lock.yaml, package-lock.json, npm-shrinkwrap.json, yarn.lock(classic과 Berry), bun.lock |
npm |
| Python | poetry.lock, uv.lock, Pipfile.lock, pdm.lock, requirements.txt(== 고정만) |
PyPI |
| PHP | composer.lock, 개발용 패키지 포함 |
Packagist |
| Ruby | Gemfile.lock, gems.locked |
RubyGems |
| Go | go.mod, 그리고 빌드에 쓰는 Go 툴체인 |
Go |
| Java와 Kotlin | gradle.lockfile, buildscript-gradle.lockfile, pom.xml |
Maven |
| Rust | Cargo.lock |
crates.io |
| .NET | packages.lock.json |
NuGet |
| Dart와 Flutter | pubspec.lock |
Pub |
| Elixir | mix.lock |
Hex |
| Swift | Package.resolved |
Swift 패키지 |
다음 두 가지 파일은 검사할 수 있게 만드는 방법을 알려 주기 위해서만 인식합니다.
- **
bun.lockb**는 Bun의 바이너리 잠금 파일입니다.bun install --save-text-lockfile을 실행하고, 생성된bun.lock을 커밋한 뒤 그 파일을 고르세요. - 잠금 파일이 없는 Gradle 빌드(
build.gradle또는build.gradle.kts)는 검사할 수 없습니다. 의존성 잠금(dependencyLocking { lockAllConfigurations() })을 켜고,./gradlew dependencies --write-locks를 실행하고,gradle.lockfile을 커밋한 뒤 그 파일을 고르세요.
이런 파일과 Lockpick이 읽지 못한 잠금 파일에 대해서는, 댓글이 검사하지 못했다고 알려 줍니다. 풀 리퀘스트에 문제가 없다고 말하는 일은 없습니다.
켜기
필요한 것:
- 설정, 이어서 저장소에서 GitHub 저장소를 연결한 사이트
- 워크스페이스의 Deep 또는 Master Key
- 사이트 관리 권한
저장소를 연결하면 풀 리퀘스트 댓글이 켜집니다. 스위치는 사이트마다 하나씩, 설정, 이어서 GitHub에 있습니다. 거기서 끄면 같은 저장소를 다시 연결해도 꺼진 상태로 남고, 다른 저장소를 연결하면 다시 켜집니다. Deep도 Master Key도 없으면 스위치에 "켜져 있지만 일시 중지됐어요"라고 표시되고, 아무것도 올라가지 않습니다.
저장소를 연결하면 Lockpick은 찾은 잠금 파일을 최대 20개까지 모두 검사하고, 저장소를 읽을 때마다 다시 찾으므로 나중에 추가한 프로젝트도 포함됩니다. testdata와 fixtures 폴더의 잠금 파일은 제외되고, GitHub가 저장소에서 집계한 언어에 따라 어떤 파일이 먼저 오는지가 정해집니다. 대부분 Go로 된 저장소라면 그 go.mod 파일이 먼저입니다. 잠금 파일의 선택을 해제하거나, 대신 apps/web/pnpm-lock.yaml 같은 경로를 입력할 수 있습니다. 직접 고른 목록은 다시 모든 잠금 파일을 고를 때까지 유지됩니다.
댓글에 표시되는 내용
Lockpick은 풀 리퀘스트마다 댓글을 하나만 두고 그 자리에서 수정합니다. 푸시할 때마다 새 댓글을 올리지 않습니다.
잠금 파일을 건드리든 건드리지 않든, 모든 풀 리퀘스트에 댓글이 달립니다. 댓글은 풀 리퀘스트의 head에 있는 의존성 버전 중 알려진 권고가 있는 것을 직접 의존성과 전이 의존성 모두 나열합니다. 맨 위 줄은 심각도별 개수를 보여 줍니다. 예를 들면 "취약한 버전 81개: 치명적 6 · 높음 14 · 보통 30"입니다. 행은 악용 확인됨이 먼저, 그다음 치명적, 높음, 보통, 낮음, 등급 없음 순으로, 그 안에서는 패키지 이름 순으로 정렬됩니다.
- 이 풀 리퀘스트가 추가하거나 바꾼 항목: 각 행에는 패키지, 버전(풀 리퀘스트가 바꿨다면 바뀌기 전 버전도), 심각도, 공격자가 이미 그 문제를 악용하고 있을 때 붙는 악용 확인됨 배지, 권고 링크, 문제를 고친 버전이 표시됩니다.
- 이 풀 리퀘스트 이후에도 저장소에 남는 항목: 기본 브랜치에 있었고 풀 리퀘스트의 head에도 여전히 있는 취약한 버전입니다. 모든 잠금 파일을 통틀어 가장 심각한 25개가 잠금 파일별로 묶여 표시되고, 나머지는 Lockpick에서 볼 수 있는 링크가 붙습니다.
- Go 저장소라면 빌드에 쓰는 Go 버전(
go.mod의toolchain줄, 없으면go줄)도 포함됩니다. 그 표준 라이브러리의 권고는 Go 표준 라이브러리라는 한 행으로 묶여, 개수와 그것을 모두 고치는 릴리스가 표시됩니다. Lockpick은 버전만 비교하므로, 도달 가능성은 검사하지 않았다고 알려 줍니다. - 풀 리퀘스트가 고치는 권고의 개수를 알려 주는 줄과, 고친 버전의 짧은 목록(패키지, 이전 버전 → 새 버전, 또는 제거됨)이 가장 심각한 것부터 표시됩니다. 처음 10개가 표시되고, 나머지는 링크로 볼 수 있습니다.
알려진 권고가 있는 버전이 없으면, 댓글은 읽은 잠금 파일과 커밋을 밝히며 그 사실을 한 줄로 알려 줍니다.
나중의 커밋으로 상황이 바뀌면 Lockpick이 댓글을 수정합니다. 오래된 경고가 남아 있지 않습니다.
Lockpick이 잠금 파일을 읽지 못하면 검사하지 못했다고 알려 줍니다. 파일이 25 MB보다 크거나, 다른 형식이거나, 없을 때 이런 일이 생깁니다. 잠금 파일이 없으면 어디를 찾아봤는지(기본 브랜치와 풀 리퀘스트의 head) 알려 주고, 저장소의 언어로 보아 맞는 잠금 파일을 제안하며, 설정으로 가는 링크를 줍니다. 파일을 읽지 않았는데 풀 리퀘스트에 문제가 없다고 말하는 일은 없습니다.
Go 취약점 데이터베이스의 많은 권고처럼, 심각도가 없는 권고도 있습니다. 이때 Lockpick은 가지고 있는 일치하는 CVE나 GitHub 권고의 심각도를 씁니다. 둘 다 없으면 그 행은 등급 없음으로 표시되고, 등급이 있는 행 다음에 나옵니다.
권한
Lockpick GitHub App은 Contents와 Metadata를 읽습니다. 이 기능을 위해서는 풀 리퀘스트를 읽고 댓글을 올릴 수 있도록, 읽기와 쓰기 권한의 Pull requests도 필요합니다.
Lockpick은 그 저장소 하나로만 제한된, 수명이 짧은 토큰을 사용합니다. 머지하지 않으며, 코드를 바꾸지 않습니다.
기존 설치
이 기능이 나오기 전에 Lockpick GitHub App을 설치했다면, GitHub에서 새 권한을 수락해야 합니다. 설치 소유자에게 이메일이 가고, GitHub가 설치의 설정 페이지에 배너를 보여 줍니다.
수락하기 전까지 설정, 이어서 저장소에는 설치로 가는 링크와 함께 권한 승인 대기가 표시됩니다. 그 전에 스위치를 켜 둘 수 있습니다. 수락하면 작동하기 시작합니다.
허용량과 한도
풀 리퀘스트 댓글은 스캔 허용량을 쓰지 않습니다. 스캔을 만들지도 않습니다.
공정하게 운영하기 위해 Lockpick은 풀 리퀘스트마다 시간당 약 20번, 워크스페이스마다 시간당 600번까지 검사합니다. 한도에 걸려 거부된 검사는 버려집니다. 한 시간이 지난 뒤의 다음 푸시에서 다시 시도하며, 항상 최신 커밋을 읽습니다.
누구의 권한으로 동작하나요
댓글은 Lockpick GitHub App이 올리지만, 스위치는 그것을 켠 관리자의 접근 권한으로 동작합니다.
- 그 사람이 사이트 접근 권한을 잃으면 기능이 스스로 꺼집니다. 다른 관리자가 다시 켤 수 있습니다.
- 워크스페이스가 Deep을 잃으면 기능이 일시 중지되고 댓글이 멈춥니다. 업그레이드하면 저절로 다시 시작됩니다.
끄기
스위치를 끄거나, 저장소 연결을 해제하거나, 다른 저장소를 고르면 Lockpick이 멈춥니다. 이미 GitHub에 있는 댓글은 그대로 남습니다. Lockpick은 그 댓글을 절대 지우지 않습니다.
GitHub에서 Lockpick GitHub App을 제거하면, Lockpick은 저장소에 대한 모든 접근 권한을 잃습니다.
두 사이트가 같은 저장소를 쓰는 경우
두 Lockpick 사이트가 같은 저장소를 연결하면, 그중 한 사이트만 댓글을 유지합니다. 풀 리퀘스트에는 여전히 댓글이 두 개가 아니라 하나만 달립니다.
도움이 되었나요?
감사합니다. 이 페이지를 개선하는 데 도움이 됩니다.