9P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • vet은 curl | bash 방식의 원격 설치 스크립트 실행을 "다운로드→검토→실행 승인" 프로세스로 안전하게 전환해주는 CLI 툴임
  • 스크립트 변경 내역(diff) 확인, shellcheck 기반 린트(정적 분석), 직접 승인(확인 후 실행) 등 단계별 방어 기능을 제공
  • 단일 명령어(vet https://example.com/install.sh)로 원격 스크립트 실행 전 잠재적 위험·변조·오타·취약점 자동 점검이 가능
  • 설치도 자체적으로 "다운로드 후 검토" 방식과 "curl | sh" 방식 모두 지원하며, vet 자체 설치 코드도 직접 확인 가능함
  • 개발/운영 환경에서의 보안 위험 예방과 자동화/편의성을 동시에 확보할 수 있는 신뢰성 높은 솔루션임

문제점: 무분별한 원격 설치 스크립트 실행

  • 많은 오픈소스·툴이 curl -sSL https://example.com/install.sh | bash와 같은 원격 스크립트 설치 방식을 안내함
  • 이 방식은 스크립트 변조/서버 해킹/네트워크 오류 등으로 인해 악성 코드 실행, 부분 파일 실행 등 치명적 보안 리스크가 존재

vet의 솔루션: 안전한 인터랙티브 실행

  • vet은 원격 스크립트 실행을 아래와 같은 4단계 보안 프로세스로 래핑함
    • 1. Fetch: 원격 스크립트를 임시 위치에 안전하게 다운로드
    • 2. Diff & Review: 이전 실행 이력과 비교해 변경점(diff) 표시, 신규/변경 코드 눈으로 직접 검토
    • 3. Lint: shellcheck(설치 시)로 버그/취약점/비정상 패턴 자동 정적 분석
    • 4. Confirm: 실제 실행 전 사용자에게 최종 승인(yes/no) 입력 요청
  • 단일 명령어:
    vet https://example.com/install.sh  
    

설치 방법

안전한 권장 방식(다운로드 → 검토 → 실행)

빠른 설치(신뢰 기반 원라인)

vet의 특징 및 장점

  • 변경 감지(diff): 이전에 실행한 스크립트와 비교해 새로 바뀐 부분을 확인할 수 있음
  • 자동 린트(shellcheck 연동): 쉘 스크립트 취약점·오타·의심 코드 자동 진단
  • 명시적 실행 승인(Confirm): 한 번의 클릭/입력으로 실제 실행을 직접 컨트롤
  • 스크립트 자동 저장·이력 관리: 자주 사용하는 설치 스크립트도 안전하게 추적 가능
  • 내부적으로 안전한 설치/업데이트도 보장

결론

  • vet은 개발자·운영자 모두에게 필요한 "curl | bash"의 안전한 대체제로, 설치 자동화와 보안 모두를 실현
  • "그냥 실행하지 말고, vet으로 검증 후 실행하세요!"
Hacker News 의견
  • 90%의 경우, 설치 프로그램을 사용할 때 소프트웨어의 신뢰성을 어떻게 실제로 검증하는지 궁금함. 어떤 경우에는 코드에 서명이 되어 있지만 많은 경우 추가 검증 없이 동일한 HTTPS 서버에서 코드가 내려옴. 코드가 컴파일된 상태라면 diff를 하는지도 질문함. 무작정 인터넷에서 설치 프로그램을 실행하는 것은 좋은 방식은 아니며, 운영 체제의 배포판에서 설치한다면 훨씬 나은 검증 방식이 마련되어 있다는 사실 언급. 이런 방법들은 신뢰를 더하는 데 큰 도움이 되지는 않음
    • vet의 목적은 설치 스크립트 자체의 보안에 초점을 두고 있으며, 설치 스크립트가 체크섬 검증을 건너뛰거나 악의적인 URL에서 바이너리를 내려받도록 변경되는 것을 방지하는 데 중점 둠. 한 부분에서는 강력한 보호 역할을 하지만 전체 체인을 담당하지는 않음
    • 설치 프로그램은 대체로 한 번만 실행되고, 이전 실행과의 변경 사항을 보여주는 것이 얼마나 유용한지 의문임
    • 신뢰성 있는, 크립토그래픽 서명된 커뮤니티 관리 패키지 리스트를 통해서만 설치하며 보안 이력이 탄탄한 방식을 이용. 근본적인 문제는 다운로드 스크립트의 보안이 어렵다기보단, macOS 등 특정 커뮤니티에서 이런 해킹스러운 설치 방식을 받아들이는 문화라고 생각. 신뢰할 수 있는 플랫폼에 더 강력한 요구가 필요. 인터넷에서 받은 셸 스크립트를 Lint 돌려본다고 해서 보안이 강화된다고는 생각하지 않음
  • 누군가 악의적인 스크립트에 # shellcheck disable= 프래그마를 계속 삽입한다면 어떻게 될지 의문
    • 좋은 지적임. 그렇게 할 수 있음. vet는 ShellCheck만 믿지 않고, diff가 핵심임. lineter가 침묵하더라도 diff를 통해 우려스러운 # shellcheck disable= 코드의 삽입을 검출. 이 변화 자체가 경고 신호임
  • 아이러니함이 느껴짐:
    # 리모트 스크립트를 맹신하는 상황:
    curl -sSL https://example.com/install.sh | bash
    
    다음으로
    curl -sL https://getvet.sh | sh
    
    이렇게 실행
    • 그 부분을 읽지 않고 넘겼던 듯. vet의 핵심은 아이러니 자체를 인지하고 있다는 점임. 사용자가 vet의 설치 스크립트를 직접 확인하도록 권장. vet의 목표가 바로 그것임. install.sh 소스를 직접 볼 수 있음
  • 정말 멋진 솔루션이라고 생각. 이런 고민을 종종 해왔고, uv 등에서도 이런 점이 궁금했음. 하지만 대부분의 경우, 코드 관리자를 모두가 신뢰하기에 타협적으로 사용
    • uv에 대해 어떤 생각을 가지고 있는지 궁금함
  • 이 논의를 보고 vet의 다음 단계로 프라이빗 환경 지원을 고민하게 됨. 공개 스크립트를 검증하는 것도 좋지만, 내부 GitHub repo나 내부 서버에서 배포 스크립트 실행도 필요해짐. 이에 대해 vet에 인증 기능 추가 기능 요청을 오픈함. .netrc 지원, VET_TOKEN 환경 변수, 추후에는 HashiCorp Vault 같은 시크릿 매니저 연동까지 로드맵에 포함. 관심 있으면 GitHub 이슈에서 의견을 듣고 싶음. 피드백 고마움
  • 페이지나 readme에 작동하는 모습이나 시연 영상을 보여줄 수 있는지 궁금함. pager나 editor로 여는지, shellcheck 경고는 어떤 식으로 보여주는지 질문
    • 맞는 말임. README에는 vet의 동작 원리만 나와 있고, 실제 사용 경험을 잘 보여주지는 못함. 페이지에 데모 GIF를 추가할 예정임. 질문에 답변하자면, 기본적으로 pager(less, 또는 bat이 설치되어 있으면 더 보기 좋은 하이라이팅 pager)로 파일을 열고, 편집기는 실수로 수정하는 걸 막기 위해 열지 않음. ShellCheck에서 문제를 감지하면 터미널에 컬러풀하게 바로 출력함. 그리고 리뷰 계속 여부를 [y/N] 형태로 직접 묻게 됨. 예시:
      ==> Running ShellCheck analysis...
      
      In /tmp/tmp.XXXXXX line 7:
      echo "Processing file: $filename"
                 ^-- SC2086: Double quote to prevent globbing and word splitting.
      
      ==> WARNING: ShellCheck found potential issues.
      [?] Continue with review despite issues? [y/N]
      
      좋은 제안 고마움
  • curl | bash 패턴처럼 자동으로 동작하지 않는 점이 아쉬움. Windows는 사용자가 설치하려고 할 때 자동으로 파일을 스캔해주는 기능이 있음
  • 아이디어가 너무 좋음. 이와 같은 보안 도구에서 가장 큰 과제는 LLM의 비결정성과 코드가 서드파티 API로 전송되는 개인정보 위험임. vet가 ShellCheck에 의존하는 이유가 바로 이것임. ShellCheck는 결정론적이고, 규칙 기반의, 완전히 오프라인에서 작동하는 linter임. 같은 입력엔 항상 같은 신뢰성 있는 출력 제공. 더 똑똑한 분석을 위해서는 언젠가 vet에 빠르고 로컬에서 실행되는 AI가 필요한 방향이라고 생각. 좋은 고민거리임
  • 정말 기발한 아이디어임. 추가 기능으로 쉘 스크립트 내용을 LLM에 전달해서 보안상 의심되는 부분을 알아내는 것도 흥미로운 방법임
  • Hi HN, vet 개발자임. 항상 curl | bash 패턴이 불안했는데, 스크립트가 변경됐을 때 diff를 보여주고, shellcheck 돌려보고, 사용자의 명시적 허가를 구하는 도구가 필요하다고 느낌. 그래서 vet를 만들었음. 설치도 같은 원칙을 적용. 설치 스크립트를 꼭 읽어보길 권장함. 피드백 환영. 레포는 https://github.com/vet-run/vet
    • 이런 문제에 대해 고민하는 사람이 나뿐만 아니라서 기쁨. 취약점 공격에 노출되는 지점이라고 생각. nvm을 예시로 든 걸 보고 재미있었음(과거에 nvm에도 비슷한 문제 제기해본 적 있음). 다만 threat model이 다소 불명확함. SSL 변조 공격자가 악의적 스크립트를 제공할 정도면, 진짜 스크립트가 다운로드한 바이너리도 악의적으로 바꿀 수 있을 만큼 고도화되어 있다고 봄. 크립토그래픽 해시를 이용한 검증을 모두가 관리하는 게 어렵긴 해도 궁극적으론 가장 확실한 방법임. 1) 원격 입력을 가져오고, 커밋된 해시와 비교 2) 인터넷이 차단된 샌드박스에서 실행 3) 검증되지 않은 해시로 페이로드 수신차단
    • "스크립트가 바뀌었을 때 diff를 보여주고 shellcheck를 돌리는" 이유가 무엇인지 질문. shellcheck의 역할이 뭔지 생각해 본 적 있는지, 언제 diff가 동작한다고 생각했는지 물음. "실행 전 명시적 허가 요청"도 그저 들여쓰기만 바꾸는 것에 불과하다면 소용없음. 작은 셸 스크립트는 금방 읽을 수 있지만, 큰 설치 프로그램은 여러 정당한 이유로 난해한 코드 스타일이 쓰임. vet가 어떤 철학을 언급하는지 모르겠음. vet가 하는 방식은 사실상 공격자들이 악성코드 배포할 때 쓰는 패턴과 비슷하다고 생각함(예시: wget -qO- https://getvet.sh로 다운받으면 서버가 text/html로 돌아오고 있음). 오히려 install.sh 직접 가져오기를 권하고 싶음. 피드백 요청엔 "이런 식으로 해보라"고 bash 팁 공유:
      check () {
        echo "> $BASH_COMMAND" >&2
        echo -n "Allow? (yes/no) " >&2
        select c in yes no
        do
          if [ "$c" = "yes" ]
          then break
          elif [ "$c" = "no" ]
          then return 1
          fi
        done
      }
      
      shopt -s extdebug
      trap check DEBUG
      
      이 방식은 bash가 무언가 실행하려 할 때마다 허가를 요구. 긴 스크립트는 번거로울 수 있으니, 안전하다고 생각되는 명령을 화이트리스트로 관리하거나 "remember" 옵션으로 커스텀 가능. sudo와 관련해선, 악성코드는 innocuous한 명령에서 sudo를 먼저 실행시키고 자격 증명을 캐시에 저장한 뒤, 아무 경고 없이 나중에 sudo 명령을 다시 실행하는 수법을 사용할 수 있음. sudo -k로 세션 캐시를 지운 후 알 수 없는 프로그램을 실행하는 게 안전함
    • 문제를 발견하고 해결책을 만들려는 시도는 평가하지만, shellcheck 본연의 역할은 바이러스/취약점 검사가 아니라서 vet의 방향이 크게 유효하지 않을 것 같음
    • 아이디어 자체가 좋음. vet는 개발자에게 소스 코드가 눈에 잘 보이고 직접 읽을 수 있을 때 유용하게 동작할 것임. 아직 내 실력으론 힘들어서 대부분 사용자 입장과 소수 사용자 입장 중 어디에 해당하는지 모르겠다는 의견임