FreeBSD 보안 업데이트 및 패키지 패치 방법

FreeBSD의 보안 업데이트 처리 방식

FreeBSD는 두 가지 별도의 도구를 사용하여 보안 업데이트를 처리합니다. FreeBSD 서버는 두 개의 독립적인 영역으로 구성되기 때문입니다. 커널과 릴리스에 포함된 사용자 공간(userland)으로 구성된 베이스 시스템은 freebsd-update을 통해 패치합니다. 그 위에 설치한 모든 소프트웨어는 패키지이며, 패키지는 pkg를 통해 패치합니다. 둘 중 하나만 실행하고 나머지를 건너뛰면 시스템의 절반은 패치되지 않은 상태로 남게 되며, 시스템은 이를 사용자에게 알리지 않습니다.

SSD Nodes는 FreeBSD 이미지를 제공하지 않습니다. 당사의 플랜은 Linux에서 실행됩니다. 그럼에도 이 글을 작성한 이유는 독자층이 완전히 겹치기 때문입니다. 당사의 Ubuntu 및 Debian 서버를 운영하는 사용자는 방화벽이나 개인적으로 관리하는 장비에서 FreeBSD를 함께 운영하는 경우가 많습니다. 이 분리된 패치 모델은 Linux 관리자가 흔히 간과하는 부분이므로 기록할 가치가 있습니다. 아래의 모든 명령어, 권고 사항 형식 및 지원 날짜는 2026년 8월 기준으로 FreeBSD 보안 페이지와 프로젝트 매뉴얼 페이지를 대조하여 확인했습니다.

명령어를 실행하기 전 한 가지 주의할 점이 있습니다. FreeBSD는 베이스 시스템에 sudo을 기본으로 설치하지 않습니다. 이 문서의 모든 작업은 root 권한이 필요합니다. su -를 사용하거나, 먼저 패키지에서 sudo 또는 doas을 설치하십시오.

기본 시스템과 패키지는 별개의 영역입니다

Ubuntu에서는 apt이 시스템 전체를 관리합니다. 커널, openssl, nginx 및 사용자가 설치한 도구들은 모두 하나의 도구에서 .deb 파일 형태로 제공되며, apt upgrade이 이들을 일괄적으로 관리합니다.

FreeBSD는 이를 둘로 나눕니다. 기본 시스템은 하나의 단위로 빌드되고 버전이 관리됩니다. 15.1-RELEASE-p3는 커널, C 라이브러리, sshd, 그리고 /usr/lib에 포함된 OpenSSL 복사본을 모두 아우르는 단일 번호입니다. 이 중 어떤 것도 pkg를 통해 제공되지 않습니다. 그 외의 모든 것은 /usr/local 아래에 위치하며, ports 트리에서 빌드된 바이너리 패키지 형태로 제공되고 각자의 버전을 가집니다.

따라서 한 대의 서버에 OpenSSL 복사본이 두 개 존재할 수 있습니다. freebsd-update에 의해서만 패치되는 /usr/lib의 기본 복사본과, pkg에 의해서만 패치되는 /usr/local/lib의 패키지 복사본입니다. 프로그램이 어느 것을 사용할지는 해당 프로그램이 어떤 라이브러리에 링크되었는지에 따라 결정되며, 패키지로 설치된 소프트웨어는 대개 패키지 복사본을 링크합니다. 한쪽을 패치한다고 해서 다른 쪽이 영향을 받지는 않습니다.

현재 상태를 확인하는 세 가지 명령어가 있습니다.

freebsd-version -u
freebsd-version -k
uname -r

freebsd-version -u은 설치된 사용자 영역(userland)의 패치 레벨을 출력합니다. freebsd-version -k는 설치된 커널의 패치 레벨을 출력하며, freebsd-version(1)은 이것이 왜 uname과 다를 수 있는지 명확히 설명합니다. "새 커널이 설치되었으나 시스템이 아직 재부팅되지 않았다면, freebsd-version은 새 커널의 버전과 패치 레벨을 출력합니다." uname -r는 현재 실행 중인 커널을 출력합니다. 또한 freebsd-version -r도 있는데, 이는 실행 중인 커널을 출력하지만 "환경 변수의 영향을 받지 않습니다". 이는 UNAME_r이 종종 다른 값으로 설정되는 jail 내부에서 중요하게 작용합니다.

보안 권고 및 정오표 공지

FreeBSD 보안 팀은 두 가지 종류의 공지를 발행하며, 각각 의미하는 바가 다릅니다.

보안 권고(Security Advisory)는 베이스 시스템의 보안 취약점을 다룹니다. 식별자는 FreeBSD-SA-26:55.elf 형식을 따릅니다. 즉, SA이라는 문자, 두 자리 연도, 해당 연도에 순차적으로 부여되는 번호, 그리고 영향을 받는 구성 요소로 구성됩니다. FreeBSD-SA-26:52.if_wg와 FreeBSD-SA-26:50.kqueue은 모두 2026-07-29에 발행되었습니다. 전체 목록은 FreeBSD 권고 페이지에서 확인할 수 있습니다.

정오표 공지(Errata Notice)는 보안 영향은 없으나 릴리스 브랜치에 반영할 가치가 있는 정확성 또는 안정성 문제를 다룹니다. 형식은 동일하며 SA 대신 EN이 사용됩니다(예: FreeBSD-EN-26:19.zfs, FreeBSD-EN-26:18.tzdata). 표준 시간대 데이터 업데이트가 대표적인 예입니다. 오래된 표준 시간대 데이터로 공격을 수행할 수는 없지만, 수정 사항을 적용하기 전까지는 타임스탬프가 부정확하게 표시됩니다. 정오표는 FreeBSD 정오표 공지 페이지에 나열되어 있습니다.

두 공지 모두 보안 담당자의 PGP(pretty good privacy) 키로 서명되어 security.FreeBSD.org에 보관되며, freebsd-update을 통해 시스템으로 전달됩니다.

리눅스 관리자들이 흔히 간과하는 부분이 있습니다. 두 공지 모두 패키지는 다루지 않습니다. 보안 페이지에는 FreeBSD Ports Collection의 문제는 "FreeBSD VuXML 문서에서 별도로 다룬다"고 명시되어 있습니다. nginx 패키지의 원격 취약점은 SA 번호를 부여받지 않습니다. 보안 권고 피드만 모니터링한다면 해당 취약점에 대해 알 수 없습니다.

FreeBSD 보안 업데이트 소식은 어떻게 확인합니까?

가입해야 할 메일링 리스트는 freebsd-security-notifications입니다. 이 리스트는 관리자에 의해 운영되며 발송량이 적고, 보안 권고문(advisory)과 정오표(errata notice)가 직접 전달됩니다. lists.freebsd.org에서 구독하십시오.

freebsd-announce 역시 관리자가 운영하며 보안 권고문과 릴리스 공지를 함께 발송하므로, 모든 소식을 하나의 리스트에서 받고 싶을 때 적합합니다. freebsd-security은 토론용 리스트입니다. 읽어볼 만한 내용은 많지만, 패치가 필요한 시점을 확인하는 용도로는 적절하지 않습니다.

이 모든 리스트는 베이스 시스템에 관한 소식만 다룹니다. 패키지 취약점 정보는 메일로 발송되지 않습니다. 패키지 취약점은 명령어를 실행하여 확인해야 합니다.

pkg audit 및 관련 데이터베이스

VuXML(Vulnerabilities and Exposures Markup Language)은 FreeBSD 프로젝트에서 관리하는 포트 및 패키지의 보안 문제 기록입니다. 각 항목에는 영향을 받는 패키지, 취약한 버전 범위, CVE(Common Vulnerabilities and Exposures) 식별자 및 간단한 설명이 포함되어 있습니다. 전체 목록은 VuXML 색인에서 패키지별, CVE별 또는 날짜별로 정렬하여 확인할 수 있습니다.

pkg audit은 이를 읽어 들이는 도구입니다:

pkg audit -F

-F는 검사 전 데이터베이스의 최신 사본을 가져옵니다. 매번 이 옵션을 사용하십시오. -F 없이 실행하면 시스템에 이미 저장된 사본을 기준으로 검사하게 되는데, 이는 수개월 전의 데이터일 수 있으므로 결과가 아무런 의미가 없을 수 있습니다. 이 명령은 설치된 모든 패키지 버전을 모든 VuXML 항목과 비교하며, 일치하는 항목이 발견되면 CVE 번호와 VuXML 페이지 링크를 출력합니다. 마지막에는 설치된 패키지 중 몇 개에서 몇 개의 문제가 발견되었는지 요약된 줄이 표시됩니다.

pkg-audit(8)에서 유용한 두 가지 플래그가 더 있습니다. pkg audit -r는 "취약한 패키지에 의존하여 잠재적으로 취약할 수 있는 패키지까지 출력"합니다. 이를 통해 설치된 6개의 프로그램이 특정 취약 라이브러리를 참조하고 있어 문제가 된다는 사실을 파악할 수 있습니다. pkg audit -R는 결과를 JSON이나 다른 기계 판독 가능한 형식으로 출력하며, 이는 모니터링 체크 도구에 전달할 때 사용합니다.

pkg 패키지는 /usr/local/etc/periodic/security/410.pkg-audit에 주기적인 스크립트를 설치합니다. 이 스크립트는 일일 보안 점검의 일부로 실행되며 결과를 root 계정으로 메일 발송합니다. /etc/periodic.conf에 다음 줄을 추가하여 활성화되어 있는지 확인하십시오:

daily_status_security_pkgaudit_enable="YES"

이 일일 메일은 FreeBSD에서 Ubuntu의 unattended-upgrades 관습과 가장 유사한 기능입니다. 하지만 그 차이가 핵심입니다. unattended-upgrades는 잠든 사이에 수정 사항을 자동으로 설치하지만, pkg audit는 수정이 필요하다는 사실만 알려줍니다. pkg audit은 보고만 할 뿐, 패치를 수행하지 않습니다. 기본 FreeBSD 시스템에서는 사용자의 개입 없이 보안 업데이트를 설치하는 기능이 없습니다.

취약한 패키지 수정하기

pkg update
pkg upgrade

FreeBSD 패키지 저장소에는 보안 전용 패키지 저장소(security-only pocket)가 존재하지 않습니다. Ubuntu는 noble-security에서만 패키지를 가져와 나머지 패키지는 그대로 둘 수 있지만, FreeBSD에는 이에 대응하는 기능이 없습니다. 따라서 취약한 패키지 하나를 수정한다는 것은 저장소에서 현재 제공하는 버전과 그에 따른 모든 의존성 패키지를 함께 업데이트한다는 의미입니다. 패키지 패치는 백그라운드 작업이 아닌 하나의 변경 작업으로 계획하십시오.

사용 중인 저장소 브랜치에 따라 수정 사항이 적용되는 속도가 결정됩니다. 기본값은 quarterly 브랜치이며, 핸드북에서는 이를 기능 업데이트를 제외하여 "더 예측 가능하고 안정적인 경험"을 제공하는 브랜치로 설명합니다. latest 브랜치는 모든 패키지의 최신 버전을 포함합니다. 따라서 pkg audit -F가 패키지의 취약점을 보고했는데 pkg upgrade은 업데이트할 내용이 없다고 한다면, 해당 수정 사항이 아직 사용 중인 브랜치에 반영되지 않은 것이며, 이러한 메커니즘이 혼란의 원인이 됩니다.

시스템을 latest 브랜치로 전환하려면 시스템에 포함된 저장소 파일을 복사한 뒤 해당 복사본을 수정하십시오.

mkdir -p /usr/local/etc/pkg/repos
cp /etc/pkg/FreeBSD.conf /usr/local/etc/pkg/repos/FreeBSD.conf

복사본의 url 줄에서 quarterly를 latest로 변경한 다음, pkg update -f을 실행하여 새 카탈로그를 가져오십시오. 저장소 이름을 기억에 의존해 입력하지 말고 파일을 직접 복사하십시오. /etc/pkg/FreeBSD.conf 내부의 이름이 시스템에서 실제로 사용하는 이름이며, /usr/local/etc/pkg/repos 아래의 파일은 이름이 정확히 일치하는 저장소 설정만 덮어씁니다.

기본 시스템 패치 적용

freebsd-update fetch
freebsd-update install

fetch은 현재 릴리스에 대한 패치를 다운로드하고 변경될 파일 목록을 출력합니다. 수행할 작업이 없으면 No updates needed to update system to 15.1-RELEASE-p3.을 출력하고 종료합니다. 수행할 작업이 있으면 설치 명령을 실행하라는 안내와 함께 종료됩니다. freebsd-update install를 실행하기 전까지는 아무것도 적용되지 않으므로, fetch은 언제든지 안전하게 실행할 수 있습니다.

freebsd-update(8)은 ALPHA, BETA, RC 및 RELEASE 버전에 대한 바이너리 업데이트를 제공하며, PRERELEASE, STABLE 또는 CURRENT 버전은 지원하지 않습니다. stable/15를 추적하는 경우 소스에서 직접 빌드해야 하며, 이 도구는 사용할 수 없습니다.

다운로드는 자동화하고 설치는 수동으로 진행하십시오. 핸드북의 /etc/crontab 관련 설정 줄은 다음과 같습니다.

@daily                                  root    freebsd-update cron

freebsd-update cron은 1에서 3600초 사이의 임의 시간 동안 대기한 후 fetch과 동일하게 업데이트를 다운로드하며, 대기 중인 업데이트가 있으면 root 계정으로 메일을 보냅니다. 임의 대기 시간을 두는 이유는 인터넷상의 모든 FreeBSD 시스템이 동시에 업데이트 미러에 접속하는 것을 방지하기 위함입니다.

출력 내용 중 두 가지가 사용자들에게 혼란을 줄 수 있습니다. src component not installed, skipped은 소스 트리가 없는 서버에서는 정상이며 오류가 아닙니다. 구성 요소 세트는 /etc/freebsd-update.conf 파일의 Components 줄에 의해 제어되며, 선택 가능한 항목은 src, world, kernel입니다.

설치 과정에서 문제가 발생하면 freebsd-update rollback를 사용하여 가장 최근에 설치된 업데이트를 제거할 수 있습니다. ZFS 루트를 사용 중이라면 더 나은 방법으로, 먼저 부트 환경(boot environment)을 생성하십시오.

bectl create pre-patch
freebsd-update fetch install

패치된 시스템이 부팅되지 않으면 로더 메뉴에서 이전 부트 환경을 선택하여 원래 상태로 되돌릴 수 있습니다. 이러한 탈출구는 ZFS를 루트 파일 시스템으로 사용하는 실질적인 이유 중 하나이며, 두 환경이 달라지기 전까지는 디스크 공간을 거의 차지하지 않습니다.

사용 중인 FreeBSD 릴리스가 여전히 지원됩니까?

각 릴리스는 보안 페이지의 브랜치 표에 게시된 고정된 기간 동안 지원됩니다. 2026년 8월 기준으로 해당 표의 내용은 다음과 같습니다.

• releng/15.1(15.1-RELEASE): 2027년 3월 31일까지
• releng/15.0(15.0-RELEASE): 2026년 9월 30일까지
• releng/14.4(14.4-RELEASE): 2026년 12월 31일까지
• stable/15: 2029년 12월 31일까지
• stable/14: 2028년 11월 30일까지

포인트 릴리스의 지원 기간은 짧습니다. 15.0-RELEASE는 15.1이 출시되면서 지원 종료 시점이 정해졌으므로, 이 글이 작성된 시점으로부터 약 7주 뒤에 지원이 종료됩니다. 안정화 브랜치는 수년간 유지되지만, 이는 freebsd-update에서 제공하지 않는 소스 브랜치입니다.

freebsd-version -u 명령으로 현재 버전을 확인하고 표와 비교하십시오. freebsd-update 명령으로도 경고를 받을 수 있습니다. 지원 종료일이 다가오면 fetch 명령은 다음을 출력합니다.

WARNING: FreeBSD 15.0-RELEASE is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.

날짜가 지나면 경고는 WARNING: FreeBSD 15.0-RELEASE HAS PASSED ITS END-OF-LIFE DATE.로 바뀝니다. 지원이 종료된 릴리스도 계속 작동은 합니다. 하지만 보안 권고를 더 이상 받지 못하므로, 향후 발견되는 기본 시스템 취약점은 사용자가 영구적으로 떠안게 됩니다.

릴리스 업그레이드는 freebsd-update -r 15.1-RELEASE upgrade를 실행한 뒤 freebsd-update install을 수행하고, 재부팅 후 freebsd-update install을 다시 실행합니다. 그 다음 pkg-static upgrade -f을 통해 모든 패키지를 새로운 라이브러리에 맞춰 재설치하고, 마지막으로 freebsd-update install를 수행합니다. 핸드북에 따르면 라이브러리 버전 번호 변경 여부에 따라 설치 단계가 3개가 아닌 2개일 수도 있습니다. 유지보수 시간을 확보하고, 시작하기 전에 FreeBSD 15 서버 설정 가이드를 읽어보십시오.

재부팅이 필요한가, 아니면 서비스 재시작으로 충분한가?

FreeBSD는 다음 비교를 통해 이에 대한 답을 제시합니다.

freebsd-version -k
uname -r

freebsd-version -k은 디스크에 있는 커널이고, uname -r은 메모리에 로드된 커널입니다. 두 문자열이 다르면 새로운 커널이 설치되었으나 현재 실행 중인 커널은 이전 버전이라는 의미이므로 재부팅해야 합니다. 문자열이 일치하면 패치가 커널에 영향을 주지 않았다는 뜻이므로 재부팅은 아무런 이득이 없습니다.

사용자 영역(userland) 패치의 경우, 패치된 코드를 사용하는 모든 대상을 재시작하십시오. /usr/lib의 기본 OpenSSL에 적용된 수정 사항은 3주 전에 시작되어 여전히 구버전 라이브러리를 주소 공간에 매핑하고 있는 sshd에는 아무런 영향을 주지 못합니다. 디스크상의 파일은 새것이지만, 실행 중인 프로세스는 그렇지 않기 때문입니다.

service sshd restart

동일한 규칙이 패키지에도 적용됩니다. pkg upgrade는 디스크의 바이너리를 교체하지만 실행 중인 프로세스는 여전히 이전 바이너리를 붙잡고 있으므로, service nginx restart를 수행해야만 수정 사항이 실제로 반영됩니다.

기본 시스템에는 Debian의 needrestart과 같은 기능이 없으므로, 아무것도 사용자에게 알리지 않으며 목록을 유지하지도 않습니다. 어떤 서비스가 패치된 라이브러리를 링크하고 있는지 추적하거나, 기본 라이브러리를 건드리는 모든 패치 이후에는 재부팅을 수행하십시오. 설정이 버전 관리 시스템에 저장된 서버라면 재부팅은 일상적인 작업이며, 패치되었다고 믿고 있지만 실제로는 그렇지 않은 상태로 운영하는 것보다 훨씬 안전하고 비용이 적게 듭니다.

Jail을 실행하는 머신 패치하기

Jail은 호스트 커널을 공유하므로, 커널 보안 권고는 호스트의 문제입니다. 따라서 호스트의 커널을 패치하고 재부팅하면 모든 Jail의 커널 패치가 완료됩니다. 각 Jail 내부의 사용자 공간(userland)은 별도의 설치 환경이며 고유한 패치 수준을 가집니다. 호스트에서 freebsd-version -j <jail>을 실행하면 이를 확인할 수 있습니다. Jail 내부의 패키지 역시 별도로 관리되며, Jail에 직접 진입하지 않고도 pkg -j <jail> audit -F을 통해 감사할 수 있습니다. 이러한 커널 공유와 사용자 공간 분리라는 구조적 차이는 Jail과 Docker 컨테이너의 비교를 결정짓는 핵심 요소입니다.

Ubuntu에서의 대응

FreeBSD의 각 습관은 대응하는 방식이 있으므로, 운영 루틴을 양방향으로 전환할 수 있습니다.

• 베이스 시스템 패치: freebsd-update fetch 후 freebsd-update install를 실행합니다. Ubuntu에서는 베이스 시스템과 기타 모든 패키지를 한 번에 처리하는 apt update && apt upgrade를 사용합니다.
• 서드 파티 소프트웨어: FreeBSD에서는 pkg update && pkg upgrade를 사용합니다. Ubuntu에서는 다시 apt를 사용합니다.
• 알려진 취약점 점검: FreeBSD에서는 pkg audit -F를 사용합니다. Ubuntu 24.04에서 가장 유사한 명령어는 pro security-status이며, 이는 Expanded Security Maintenance 콘텐츠를 포함하여 설치된 패키지에 대한 보안 업데이트를 보여줍니다.
• 자동 설치: Ubuntu의 unattended-upgrades는 보안 업데이트를 자동으로 적용합니다. FreeBSD는 이와 동일한 기능을 제공하지 않으므로, freebsd-update cron를 통해 업데이트를 다운로드하고 메일로 알림을 받은 뒤 수동으로 설치해야 합니다.
• 권고 피드: freebsd-security-notifications는 FreeBSD-SA 및 FreeBSD-EN 항목을 제공합니다. ubuntu-security-announce는 Ubuntu Security Notices를 제공합니다.
• 취약점 데이터베이스: FreeBSD 포트 및 패키지에는 VuXML이 있습니다. Ubuntu 패키지에는 Ubuntu CVE tracker가 있습니다.
• 재부팅 확인: FreeBSD의 uname -r에 대응하여 freebsd-version -k를 사용합니다. Ubuntu에서는 /var/run/reboot-required의 존재 여부를 확인합니다.
• 지원 기간: FreeBSD 보안 페이지의 브랜치 테이블을 참조합니다. Ubuntu에서는 릴리스 일정과 pro security-status를 확인합니다.

두 시스템의 근본적인 운영 루틴은 동일합니다. 피드를 구독하고, 일정에 따라 감사를 실행한 뒤, 무엇을 설치하고 언제 재시작할지 결정하는 것입니다. FreeBSD는 시스템이 자동으로 작업을 수행하지 않으므로 사용자가 직접 후반 작업을 명시적으로 수행해야 합니다. 서버 플랫폼으로서의 Linux와 FreeBSD에 대한 더 넓은 비교에서는 워크로드를 두 시스템 간에 이동할 때 변경되는 다른 사항들을 다룹니다.

FAQ

freebsd-update가 패키지도 패치합니까?

아니요. freebsd-update는 베이스 시스템만 다룹니다. 즉, 릴리스와 함께 제공된 커널과 유저랜드만 해당합니다. /usr/local 하위에 설치된 소프트웨어는 패키지에서 제공되며, pkg upgrade을 사용하여 패치합니다. 설치된 패키지 중 알려진 취약점이 있는 것을 찾으려면 pkg audit -F을 실행하십시오. 베이스 시스템 보안 권고에는 패키지 관련 내용이 포함되지 않으며 보안 메일링 리스트에서도 이를 공지하지 않기 때문입니다.

FreeBSD 업데이트 후 재부팅이 필요한지 어떻게 알 수 있습니까?

freebsd-version -k과 uname -r의 결과를 비교하십시오. 전자는 방금 기록되었으나 아직 부팅되지 않은 커널을 포함하여 디스크에 설치된 커널을 출력합니다. 후자는 현재 실행 중인 커널을 출력합니다. 두 문자열이 다르면 재부팅이 필요합니다. 문자열이 일치하면 유저랜드 패치만 적용된 것이므로, 실행 중인 프로세스는 재시작 전까지 이전 라이브러리를 메모리에 유지하므로 service sshd restart과 같이 영향을 받는 서비스를 재시작하십시오.

보안 권고(Security Advisory)와 정오표(Errata Notice)의 차이는 무엇입니까?

FreeBSD-SA-26:55.elf과 같은 보안 권고는 베이스 시스템의 보안 취약점을 수정합니다. FreeBSD-EN-26:18.tzdata와 같은 정오표는 시간대 데이터가 오래된 경우처럼 보안에 영향을 주지 않는 정확성이나 안정성 문제를 수정합니다. 두 경우 모두 연도, 콜론, 일련번호, 구성 요소 패턴을 사용합니다. 둘 다 보안 담당자(Security Officer)의 서명을 거쳐 freebsd-update을 통해 전달되며, 포트나 패키지로 설치된 소프트웨어는 다루지 않습니다.

FreeBSD에 unattended-upgrades와 같은 기능이 있습니까?

베이스 시스템에는 없습니다. freebsd-update cron는 대기 중인 베이스 패치를 다운로드하여 root 계정으로 메일을 보내지만, 자동으로 설치하지는 않습니다. pkg가 설치하는 주기적 스크립트는 매일 pkg audit을 실행하여 결과를 메일로 보내지만, 역시 아무것도 업그레이드하지 않습니다. 자동 설치는 cron 작업을 사용하여 직접 구축해야 합니다. FreeBSD 패키지 업그레이드는 보안 전용 백포트가 아닌 최신 버전을 가져오기 때문에, 대부분의 관리자는 메일을 확인한 뒤 수동으로 설치합니다.

FreeBSD 릴리스가 여전히 지원되는지 어떻게 확인합니까?

freebsd-version -u을 실행하여 유저랜드 버전을 확인한 뒤, FreeBSD 보안 페이지의 지원 브랜치 표와 비교하십시오. 포인트 릴리스의 지원 기간은 짧습니다. 2026년 8월 기준으로 15.0-RELEASE는 2026년 9월 30일에 종료되며, 15.1-RELEASE는 2027년 3월 31일까지 지원됩니다. freebsd-update fetch은 종료일이 다가오면 경고를 표시하며, 날짜가 지나면 해당 릴리스가 수명이 다했음을 알리는 문구를 출력합니다. 그 시점 이후로는 어떠한 보안 권고도 적용되지 않습니다.