Status | Authors | Coach | DRIs | Owning Stage | Created |
---|---|---|---|---|---|
proposed | devops secure | - |
GitLab Secret Detection ADR 002: 같은 리포지터리에 Secret Detection Gem 저장
컨텍스트
Phase 1에서는 리포지터리에 비밀 정보가 커밋되는 것을 막기 위해 Ruby 기반의 푸시 체크 접근 방식을 사용하기로 선택하였으며, 따라서 비밀 정보를 스캔하는 것은 GitLab 내에서 이 특정 목적을 위해 개발된 라이브러리(또는 Ruby gem)에 의해 수행되었습니다.
이 라이브러리를 만들고 Rails 모놀리스 내에서 사용할 수 있도록 하기 위한 일부 과정으로, 이 라이브러리를 배포하는 가장 좋은 방법에 대한 결정을 내려야 했습니다.
방법
두 가지 가능한 방법을 평가했습니다:
각 방식은 배포, 일관성, 유지 관리 및 리뷰 및 릴리스 워크플로우 설정과 같은 일부 장단점을 가지고 있었습니다. 자세한 내용은 아래를 참조하세요.
모놀리스와 같은 리포지터리 내에서
라이브러리를 개발하고 같은 리포지터리에 저장하는 것은 GitLab 모놀리스 자체 내에 패키징되어 있음을 의미하며, 따라서 이 라이브러리를 의존성으로 설치할 필요가 없음을 보장합니다. 이로써 처음부터 워크플로우와 프로세스를 정의하는 유지 보수 오버헤드를 줄일 수 있을 것입니다. 그러나 다른 측면에서는 라이브러리의 가시성이 상대적으로 낮아지며, 보편 커뮤니티에 노출되거나 발행되지 않기 때문입니다.
외부 리포지터리에
라이브러리를 외부 리포지터리에 저장하는 것은 특히 RubyGems.org에 게시될 예정이므로 더 많은 관심과 가능한 커뮤니티로부터의 기여를 얻게 되며, 또한 다른 프로젝트와 애플리케이션에서 사용할 수 있게 될 것입니다. 그러나 이렇게 함으로써 여러 이유로 유지 보수 오버헤드가 상당히 증가하게 될 것입니다:
- 새 버전이 릴리스될 때 여러 리포지터리 간에 변경 사항을 조율해야 함.
- 리뷰 및 릴리스 워크플로우 및 유사한 프로세스를 별도로 정의해야 함.
결정
이 결정은 첫 번째 단계에서 라이브러리를 같은 리포지터리에 저장하여 외부 의존성을 설치하지 않아도 되도록 하고자 하였으므로 이루어졌습니다.
그렇지만, 우리는 그래도 프로세스를 따라가서 RubyGems.org에서 저명-스쿼터들이 이름을 가져가서 3rd-파티들에게 악성 코드를 제공하지 못하도록 해당 gem의 이름을 예약하였습니다.
적어도 Phase 2까지는 외부에서 gem을 발행할 계획이 없으며, 비밀 검출을 수행할 독립형 서비스를 구축하는 것을 고려하기 시작할 때까지입니다.