대상 OS: Ubuntu Server 24.04 LTS

보안 패치를 해도 마음이 불안한 이유는 간단합니다.
“지금 이 서버에 어떤 취약점이 남아 있는지”를 딱 잘라 말해주는 화면이 없기 때문이죠.
업데이트를 꾸준히 했다고 해도, 보류(hold)된 패키지나 서비스 재시작/재부팅 지연으로 취약 상태가 남아 있을 수 있습니다.
또는 운영상 이유로 업그레이드를 미룬 패키지가 ‘취약점 관점’에서는 최우선이 될 수도 있습니다.

Ubuntu 24.04에서는 debsecan을 이용해 “현재 설치된 패키지 기준으로, 해당되는 CVE 목록”을 빠르게 뽑고 매일 리포트로 남길 수 있습니다.
이 글은 debsecan을 설치해 로컬 패키지 기반 CVE 점검을 만들고, 결과를 운영 우선순위로 해석하며, cron으로 자동화하는 방법을 정리합니다.

---

1) debsecan이 잘하는 것 / 못하는 것

1) 잘하는 것: 설치된 패키지 버전을 기준으로 관련 CVE를 목록화

2) 잘하는 것: “취약점이 남아있을 가능성”을 서버 단위로 빠르게 스캐닝

3) 잘하는 것: 리포트 자동화(일일 점검)로 변화 감지

4) 못하는 것: 실제 익스플로잇 가능성(노출 여부, 설정, 접근 경로)까지 완전 판정

5) 못하는 것: 컨테이너 이미지 내부까지 자동으로 분석(별도 스캔 필요)

즉, debsecan은 “우선순위 후보 리스트”를 만드는 도구입니다. 최종 판단은 노출/설정/서비스 경계를 함께 봐야 합니다.

---

2) 사전 점검: 패키지 업데이트/보류 상태부터 확인

취약점 점검을 하기 전에 “패치가 왜 안 들어갔는지”부터 확인해두면 불필요한 노이즈가 줄어듭니다.

1) 최신 인덱스 갱신 및 업그레이드 가능 여부 확인

sudo apt update
apt list --upgradable 2>/dev/null | head -n 40

2) hold(보류) 패키지 확인

apt-mark showhold || true

3) 보안 업데이트 자동화(unattended-upgrades) 사용 여부 확인(선택)

systemctl status unattended-upgrades --no-pager 2>/dev/null || true

---

3) debsecan 설치 및 기본 실행

1) 설치

sudo apt -y install debsecan

2) 기본 실행(전체)

sudo debsecan | head -n 80

3) 출력이 너무 길면 파일로 저장

sudo debsecan > /tmp/debsecan.txt
wc -l /tmp/debsecan.txt
head -n 40 /tmp/debsecan.txt

---

4) 리포트 품질 올리기: 관심 서비스(예: openssl, openssh, nginx 등) 중심으로 보기

운영에서는 “리스트 전체”보다 “내 서버에서 중요한 공격면”을 먼저 보는 편이 효율적입니다.

1) 특정 패키지 관련 CVE만 필터링(간단 검색)

sudo debsecan | grep -iE 'openssh|openssl|nginx|sudo|systemd' | head -n 80

2) 현재 서버에서 외부 노출이 있는 서비스부터 확인

sudo ss -ltnp | head -n 80
sudo ss -lunp | head -n 80

외부에 열려 있는 서비스(예: 22, 80/443)가 관련된 CVE는 우선순위를 높게 잡는 게 보통 맞습니다.

---

5) “업데이트만 하면 끝”이 아닌 케이스들(실전 함정)

1) 패키지는 업데이트됐는데 서비스가 재시작되지 않아 취약 코드가 메모리에 남아 있음

2) 커널 업데이트가 쌓였는데 재부팅을 안 해서 취약 커널을 계속 사용

3) hold로 묶어 둔 패키지에 중요한 CVE가 쌓임

4) 레거시 PPA/서드파티 repo가 보안 업데이트 경로를 깨뜨림

이런 케이스는 debsecan이 “지금 뭔가 남아 있다”는 신호를 주는 데 도움이 됩니다.

재부팅 필요 여부는 아래처럼 확인할 수 있습니다.

test -f /var/run/reboot-required && echo "reboot required" || echo "no reboot required"
uname -r

---

6) 우선순위 잡는 간단 프레임(운영자가 바로 쓰는 기준)

1) 외부 노출 서비스 관련 CVE인가

2) 인증 전(remote unauth) 공격이 가능한 성격인가

3) 권한 상승(local privilege escalation)인가

4) 해당 패키지가 우리 서버에서 실제로 사용 중인가(프로세스/포트/유닛)

5) 완화책(설정, 방화벽, 접근 경로)이 이미 있는가

기술적으로 완벽한 점수화는 어렵지만, 이 다섯 가지 질문만으로도 “오늘 처리할 것”이 빨리 보입니다.

---

7) 일일 리포트 자동화(cron): 결과를 파일로 남겨 변화 감지

1) 리포트 디렉터리 생성

sudo install -d -m 0755 /var/log/debsecan
sudo chown root:root /var/log/debsecan

2) 일일 실행 스크립트 만들기

sudo tee /usr/local/sbin/debsecan-daily >/dev/null  "${outdir}/summary.${now}.txt"
EOF
sudo chmod 0755 /usr/local/sbin/debsecan-daily

3) cron.daily에 등록

sudo tee /etc/cron.daily/debsecan-daily >/dev/null /dev/null | head -n 80

2) 보류 패키지(hold) 해제 검토

apt-mark showhold || true

3) 커널/중요 라이브러리 업데이트 후 재부팅 계획 수립

apt list --upgradable 2>/dev/null | grep -i linux | head -n 40 || true

4) 서드파티 repo가 원인이라면 제거/격리

- “편의” repo가 보안 업데이트를 늦추는 경우가 실제로 있습니다.

---

마무리

Ubuntu 24.04에서 debsecan은 “내 서버에 남은 CVE를 매일 보는 습관”을 아주 작은 비용으로 만들어 줍니다.
보안 운영은 결국 ‘가시성’ 싸움입니다.
무슨 취약점이 남아 있는지 보이면, 패치/재부팅/예외(hold) 같은 운영 의사결정이 훨씬 명확해집니다.

정리하면
- debsecan으로 로컬 패키지 기반 CVE 후보를 뽑고
- 외부 노출 서비스부터 우선순위를 잡고
- cron으로 일일 리포트를 남겨 변화(증가/감소)를 추적
이 흐름만 자리잡아도, 보안 패치 운영이 “감”이 아니라 “데이터”로 바뀝니다.