How often should I review the inventory?

Review it whenever you add or change an app, and use the relevant vendor advisory feeds to trigger security updates.

Do I need to scan every file after a patch?

Focus first on the applicable advisory, the running package or image, and the critical service behavior. Broaden checks when the change or evidence calls for it.

Can I mark an issue fixed after pulling a new image?

No. Recreate or update the service as required and verify that the replacement process uses the patched image.

What if the installed version looks older than the fixed upstream version?

Check the distribution or vendor advisory for a backported fix and the required package revision.

홈 서버 앱의 보안 권고 사항을 추적하고 패치를 검증하는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Patch the Planet official announcement cover artwork

보안 패치를 안정적으로 추적하려면 셀프 호스팅 애플리케이션마다 간단한 인벤토리에 한 행씩 기록하세요. 담당자, 런타임 출처, 노출된 주소, 업데이트 채널, 마지막으로 배포를 확인한 날짜를 포함하세요. 보안 권고가 나오면 변경하기 전에 해당 항목과 연결하세요. 저장해 둔 보안 뉴스 링크 목록은 영향을 받는 소프트웨어의 인벤토리가 아닙니다.

PHP 기반 Docker 앱의 경우 애플리케이션 공급업체의 보안 권고를 확인하고, 지원되는 이미지를 업데이트한 뒤 서비스를 다시 만들고, 새 환경 안에서 런타임을 확인하세요. 배포판 패키지를 사용하는 경우에는 백포트를 포함한 해당 배포판의 보안 지침을 따르세요. 어떤 수정 사항이 실행 중인지, 언제 배포되었는지 확인할 수 있도록 충분한 근거를 보관하세요.

실용적인 보안 인벤토리에는 무엇을 포함해야 하나요?

항목	유용한 근거의 예
애플리케이션 및 담당자	Nextcloud 인스턴스 및 유지관리 담당자
런타임 출처	공급업체 이미지 태그 및 다이제스트 또는 배포판 패키지
노출 범위	공개 호스트 이름, VPN 전용 또는 LAN 액세스
보안 권고 채널	공급업체 보안 페이지 및 릴리스 피드
복구	데이터베이스 백업, 데이터 사본, 구성 내보내기
업데이트 확인	배포 날짜 및 실행 중인 버전 또는 패키지 리비전

이 파일은 애플리케이션의 쓰기 가능한 데이터와 섞이지 않도록 유지관리 폴더에 보관하세요. 자격 증명은 다른 곳에 저장하세요. 소프트웨어 스택 가이드에서 애플리케이션 이름 아래에 숨겨진 런타임을 찾는 방법을 확인할 수 있습니다.

어떤 보안 권고를 확인해야 하나요?

인벤토리에 해당하는 애플리케이션 유지관리자, 컨테이너 게시자, 운영체제 보안 소스를 구독하세요. 런타임 정보를 파악할 때는 업스트림 PHP 보안 권고를 참고하되, 설치할 패키지나 이미지는 다운스트림 지침에 따라 결정하세요. 소스 URL과 영향을 받는 브랜치를 기록하세요.

Patch the Planet 대응 설명에서는 조사 소식, 업스트림 릴리스, 배포 가능한 애플리케이션 업데이트가 서로 다른 시점에 나올 수 있는 이유를 설명합니다.

앱이 영향을 받는지 어떻게 확인하나요?

애플리케이션을 제공하는 프로세스를 식별하세요. 공급업체가 지원하는 방법으로 해당 프로세스의 컨테이너 또는 런타임 환경을 검사하고 결과를 보안 권고의 조건과 비교하세요. 호스트에서 실행한 CLI 명령은 다른 PHP 설치 버전을 보고할 수 있습니다. 공급업체 패키지의 리비전과 문서화된 백포트를 고려하세요.

이 구분을 위해 PHP 버전 식별 가이드를 참고하세요. 근거가 불충분하면 알림이 없다는 이유만으로 안전하다고 가정하지 말고, 인벤토리 항목을 알 수 없음으로 표시하세요.

철저한 테스트 없이 업데이트를 확인하려면 어떻게 해야 하나요?

복구 가능한 데이터베이스 및 데이터 사본을 보존하고 지원되는 업데이트를 설치한 다음 세 가지를 확인하세요. 새 프로세스가 실행 중인지, 문서에 명시된 수정 사항이나 패키지 리비전이 적용되었는지, 중요한 사용자 작업 흐름이 여전히 작동하는지 확인합니다. 파일 앱이라면 로그인해 테스트 파일을 읽어 보세요. 업로드가 중요한 사용 방식이라면 작은 파일을 업로드해 보세요.

마이그레이션 단계와 롤백 제한 사항을 기록하세요. 런타임이 이미지 내부에 있는 경우 Docker 애플리케이션 업데이트 가이드를 따르세요.

권고문은 언제 완료로 표시해야 하나요?

배포된 서비스에 해당 수정 사항이 적용되고, 핵심 서비스 점검을 통과하면 완료 처리하세요. 이미지 다이제스트 또는 패키지 리비전, 날짜, 결과를 기록하세요. 이미지를 디스크에 다운로드했거나, 풀 리퀘스트를 병합했거나, 업스트림 발표를 확인한 것은 중간 단계일 뿐입니다.

원본 백업은 앱의 일반 쓰기 가능 공유 폴더와 분리해 보관하세요. ZimaCube 2에 이러한 기록과 복구 파일을 보관할 수 있습니다. 복구 가능한 사본 가이드에서 편리한 작업용 사본만을 유일한 복구 수단으로 삼아서는 안 되는 이유를 설명합니다.