Repository navigation
릴리스 PR 의 dependency-review 가 의존성 903건 전량을 신규 도입으로 오탐 — main 스냅샷 미제출 #1063
Description
📜 Overview (Required)
dependency-submission.yml 의 신뢰된 제출 job 이 push: branches: [develop] 로 한정돼 있어 main 에는 dependency snapshot 이 한 번도 제출된 적이 없다 (gh run list --workflow dependency-submission.yml --branch main → 0건). 그래서 릴리스 PR(develop → main)의 Review dependency changes 는 base 를 빈 것으로 보고 develop 의존성 전량을 added 로 계산하고, 그 안에 섞인 기존 취약점이 릴리스 PR 탓으로 걸린다.
실측 — #1025 실패 런 (25a8f31b2...efbb1256c)
gh api "repos/Afternote/Afternote-FE/dependency-graph/compare/25a8f31b2...efbb1256c"
| 항목 | 값 |
|---|---|
added |
903 |
removed |
1 (ScaCap/action-ktlint@master) |
| develop 스냅샷의 고유 패키지 수 | 903 — added 와 정확히 일치 = base 가 비었다는 증거 |
| 그중 high 이상 취약 | 8건 (netty 구버전) → 체크 실패 |
#1009 와 같은 구조가 correlator 가 아니라 ref 를 바꿔 재현된 것이다. develop base PR 은 base·head 스냅샷이 모두 존재해 드러나지 않고, 릴리스 때만 터진다.
📌 Child Issue(Optional)
No response
📍 Note (Optional)
수정 방향
- 제출 job 트리거를
push: branches: [develop, main]으로 넓힌다. correlator 는 지금의afternote-gradle-dependency-graph를 그대로 둬야 compare 가 base·head 를 짝짓는다(chore(ci): dependency-graph job correlator 불일치 — develop base PR 의 dependency-review 가 의존성 전량을 신규 도입으로 오탐 #1009 의 교훈). - 다만 이 변경만으로 다음 릴리스 1회는 여전히 오탐이다 — main 에 push 가 한 번 일어나야 비로소 스냅샷이 생긴다(chore(ci): dependency-graph job correlator 불일치 — develop base PR 의 dependency-review 가 의존성 전량을 신규 도입으로 오탐 #1009 때와 같은 부트스트랩 지연). 즉시 해소하려면
workflow_dispatch를 붙여 main 에서 1회 수동 제출하는 선택지가 있다.- 짚을 점: chore(ci): release-distribution 의 workflow_dispatch 제거 — 배포 경로를 main push 하나로 #1029(PR chore(ci): release-distribution 의 workflow_dispatch 제거 — 배포 경로를 main push 하나로 (closes 1029) [base: develop] #1033)가 release-distribution 의
workflow_dispatch를 걷어내 배포 경로를 main push 하나로 좁히는 중이다. 여긴 다른 워크플로라 기능상 충돌은 없지만 «수동 트리거를 새로 붙인다» 가 그 결정과 어긋나 보일 수 있으니 리뷰에서 판단할 것.
- 짚을 점: chore(ci): release-distribution 의 workflow_dispatch 제거 — 배포 경로를 main push 하나로 #1029(PR chore(ci): release-distribution 의 workflow_dispatch 제거 — 배포 경로를 main push 하나로 (closes 1029) [base: develop] #1033)가 release-distribution 의
함께 볼 것
- fix(build): netty 보안 하한이 AGP UTP 설정에 미적용 — 릴리스 PR dependency-review 가 high 8건으로 실패 #1058 (netty 보안 하한이 AGP UTP 설정에 미적용). 그쪽이 머지되면 high 8건이 사라져 release: develop 누적 145커밋을 main 릴리스 후보로 반영 [base: main] #1025 자체는 통과하지만, 「전량 신규 도입」 구조는 그대로 남는다.
- 이 게이트의 green 이 «취약점 없음» 을 뜻하지 않는다는 점도 그대로다 — 스냅샷이 안 맞으면 compare 가 빈 배열을 돌려주고 «변경 없음» 으로 통과한다(fix(ci): dependency-graph 두 job 의 correlator 통일 — develop base PR 의 의존성 전량 오탐 해소 (closes 1009) [base: develop] #1011 실측). 실제로 이 이슈를 작성하는 중에도 develop 이 움직여 아직 스냅샷이 없는 head SHA 가 되면서
main...developcompare 가 일시적으로 0건이 됐다.
Activity
1hyok commentedon Aug 27, 2026
PR #1182의 자동 제출 패치는
develop에는 반영됐지만 아직main에는 도달하지 않았습니다.PR #1273(
main워크플로 Action SHA 고정)의 Dependency Review에서 같은 부트스트랩 문제가 재현됐습니다.mainSHAfcef8ceb4d12f566a5304cce9164927f2d1fae62: Gradle snapshot 0건6bbec716c0ed1314574ca3bc93b6f2d18473b7d8: snapshot 1건io.netty:netty-codec:4.1.93.Finalhigh 취약점 2건을 신규 도입으로 오판직접 Dependency Submission API payload를 재작성하지 않고, 기본 브랜치의 검토된 trusted workflow가
main을 고정 checkout한 뒤 공식gradle/actions/dependency-submission으로 실제 그래프를 생성·제출하는 수동 기준선 경로를 추가하겠습니다. 임의 ref/SHA 입력은 받지 않고, snapshot SHA는 checkout된mainHEAD에서만 계산합니다.또한 #1273에는 PR #1182의
push: [develop, main]패치를 포함해 머지 이후부터 자동 갱신되도록 하겠습니다. 기준선 제출과 #1273 재검증이 끝날 때까지 이 이슈를 다시 엽니다.[-]chore(ci): 릴리스 PR 의 dependency-review 가 의존성 903건 전량을 신규 도입으로 오탐 — main 스냅샷 미제출[/-][+]릴리스 PR 의 dependency-review 가 의존성 903건 전량을 신규 도입으로 오탐 — main 스냅샷 미제출[/+]1hyok commentedon Aug 29, 2026
2026-08-30 재실측 — 이슈가 요구한 것이 이미 develop 에 다 들어와 있다
본문의 처방 두 가지가 모두 반영된 상태라 코드 변경 없이 닫는다.
1. 제출 트리거는 이미
develop, main이다dependency-submission-trusted.yml이push: branches: [develop, main]로 돌고, correlator 도 본문이 지키라고 한afternote-gradle-dependency-graph그대로다 (#1009 의 교훈이 유지됨).2. 부트스트랩 지연을 메우는 수동 제출 경로도 있다
본문이 「선택지가 있다」고 적은
workflow_dispatch1회 수동 제출이submit-main-baselinejob 으로 실재한다. 임의 입력을 받지 않고refs/heads/main을 직접 checkout 해 그 HEAD SHA 에 스냅샷을 귀속시킨다 — 본문이 우려한 「수동 트리거를 새로 붙이는 것이 #1029 의 방향과 어긋나 보일 수 있다」는 걱정도, 배포 트리거가 아니라 기준선 제출 전용이라 비켜 간다.이 구조는
supply-chain-policy.test.mjs가 이미 고정하고 있다 —workflow_dispatch존재·concurrency 표현식·job 의if조건까지 단언한다.3. 증상도 재현되지 않는다
--branch main→ 0건)99f0cea9a(2026-08-27 14:01Z) 에 제출 성공dependency-graph/comparemain…developadded903 = develop 고유 패키지 수 (base 가 비었다는 증거)added262 /removed135added가 develop 전량과 더는 일치하지 않는다 — base 스냅샷이 실제로 짝지어지고 있다는 뜻이다.남는 것
본문이 「이 게이트의 green 이 취약점 없음 을 뜻하지 않는다」고 짚은 점(스냅샷이 안 맞으면 compare 가 빈 배열을 돌려주고 «변경 없음» 으로 통과, #1011 실측)은 이 이슈의 범위가 아니라 그대로 남는다. 되살릴 조건이 생기면 그 관점의 이슈로 새로 여는 편이 낫다.