라이브러리들을 여러가지 사용하다 보면, 버전 문제로 여러가지 문제를 겪을 수 있다.
특정 버전으로 업데이트 되면서 API가 변경되어 기존 코드가 작동하지 않는 경우가 있는 등 하는 것이다.
여기서 보통 사용하는 방법은, 버전을 고정시키는 것이다.
Golang 에서는 go.mod 파일에서, javascript에서는 package.json 파일에서, python에서는 requirements.txt 파일에서 하는 등 각각의 언어마다 사용하고 있는 라이브러리의 버전을 명시할 수 있다.
취약점
그런데 버전을 고정하는 방식은 생각만큼 좋은 방법은 아니다.
혹자는 잘 동작하는 소프트웨어를 고치지 말라고 하는 사람도 있지만, 패치에는 단순히 기능 관련 업데이트 뿐 아니라, 보안 업데이트 같은 중요한 업데이트도 포함되어 있는 경우가 많기 때문이다.
Java에서 매우 흔하게 사용되는 Log4j의 경우에서도 취약점이 발견되어, 버전을 업데이트 해야 하는 사례도 있었다.
나 자신도 버그가 담긴 코드를 쓸 때가 많기에, 취약점은 언제, 어디서든 발생해도 이상하지 않다.
패치
일반적으로 취약점과 같은 경우는 버전 업데이트를 통해 패치를 할 수 있다.
다만 언제, 어떤 버전을 어떻게 업데이트 해야 되는지 모르고, 신경을 쓰고 있지 않은 개발자라면 아직도 취약점이 있는 log4j를 사용하고 있을지도 모른다.
바로 이럴 때 Dependabot이 꽤나 괜찮은 대안이 될 수 있다.
Dependabot?
Dependabot은 Github에서 제공하는 오픈소스 라이브러리 업데이트 알림 서비스이다. 리포지토리의 의존성을 주기적으로 확인하고, 새로운 버전이나 보안 취약점이 발견된 패키지를 자동으로 업데이트 해준다.
버전 변경을 감지하면 위와 같이 PR을 생성하며,
들어가보면 릴리즈 노트와 해당 버전에 포함되는 커밋 내역같은 것들도 확인할 수 있다.
파일 변경 내역에 들어가보면 다음처럼 버전을 수정한 것을 볼 수 있다.
설정하기
매우 어려워보이지만, Dependabot을 설정하는 것은 그리 어려운 편은 아니다. 아래 내용을 .github/dependabot.yml 파일에 추가하면 된다.
# To get started with Dependabot version updates, you'll need to specify which
# package ecosystems to update and where the package manifests are located.
# Please see the documentation for all configuration options:
# https://docs.github.com/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file
version: 2
updates:
- package-ecosystem: "gomod"
directory: "/"
schedule:
interval: "daily"
package-ecosystem은 사용하는 언어에 따라 다르다. 필자의 경우 golang을 사용하고 있어 gomod를 사용했다.
directory는 go.mod 파일이 있는 디렉토리를 지정해주면 된다. 필자의 경우 root 디렉토리에 있어 /로 설정했다.
schedule은 업데이트 주기를 설정하는 것으로, 필자의 경우 매일 업데이트를 확인하도록 설정했다.
해당 파일을 푸시하고 액션 탭에 들어가면 다음과 같이 Dependabot Update라는 액션이 추가된 것을 확인할 수 있으며,
실행된 내역도 수 있다.
꼭 필요한가?
버전 같은 경우는 사실 큰 문제가 없으면, 업데이트를 꼭 할 필요는 없다. 특히 메이저 버전 업데이트의 경우 하위 버전을 호환하지 않는 경우가 대부분이기 때문에 인터페이스가 변경되어 오류가 발생할 확률이 높고, 그렇지 않더라도 업데이트로 버그가 발생하는 케이스도 무수히 많다.
오픈소스와 결합되면 대환장 파티가 되기도 하는데, 아무도 코드에 대한 실질적인 책임이 없기 때문이다.
꽤 최근에는 xz-utils에서 오픈소스 공급망 공격으로 인해 백도어가 심어진 케이스도 있었다.
물론 막혔다.
업그레이드를 해서 취약점에 노출될 확률과 업그레이드를 해서 취약점이 고쳐질 확률을 생각해보면 후자가 훨씬 높다.
꼭은 아니더라도, 일반적인 관점에서 Dependabot 과 같은 도구를 활용하여 업데이트를 하는 것은 괜찮은 해결책이 될 수 있을 것이다.
주의점
버전 업데이트로 인터페이스가 변경되는 경우는 배포나 테스트시 에러를 동반하기 때문에, 기본적으로 Github Actions 와 같은 CI/CD 플랫폼에서 테스트를 돌려보도록 하는 것이 좋다.
물론 테스트의 성공이 곧 버전 업그레이드의 완벽한 성공은 보장하지 않으나. 테스트 코드가 촘촘하게 잘 구성되어 있다면, 많은 수의 버그를 미연에 방지할 수 있을 것이다.