중소기업 보안 취약점 점검 신청 방법, 홈페이지·앱·서버별로 어디까지 확인해줄까?

중소기업기본법상 중소기업이면서 국민생활과 밀접한 서비스를 운영한다면 홈페이지·모바일 앱·개발·운영 환경 점검을 신청할 수 있습니다.
신청은 보호나라의 서비스 신청하기에서 기업 보안취약점 점검을 선택하고, 대상 자산과 점검 희망 분야를 협의하는 방식으로 진행됩니다.
결과를 받았다면 위험도가 높은 인터넷 노출·계정·개인정보·파일 업로드·패치 문제부터 고치고, 조치 후 재점검과 이행 기록까지 남겨야 합니다.

중소기업 보안 취약점 점검, 먼저 대상부터 구분해보세요

홈페이지는 잘 열리고 앱도 정상적으로 작동하는데, 막상 보안 점검을 받아보면 생각하지 못한 문제가 나오는 경우가 있습니다. 관리자 페이지가 외부에 그대로 노출돼 있거나, 오래된 라이브러리를 사용하고 있거나, 서버에 불필요한 계정이 남아 있는 식이죠.

한국인터넷진흥원 KISA의 중소기업 보안 취약점 점검은 이런 해킹 원인이 될 수 있는 취약점을 찾아내고 조치 방향을 지원하는 서비스입니다. 대상은 중소기업기본법상 중소기업 가운데 국민생활과 밀접한 서비스를 제공하는 기업이며, 점검 분야는 크게 세 가지로 나뉩니다.

점검 분야	주요 대상	확인하는 내용
홈페이지	웹사이트·관리자 페이지·웹서버	중요정보 노출, 악성코드 삽입, 매개변수 변조 등
모바일 앱	iOS·Android 앱	앱 변조·유포, 중요정보 노출, 인증과 저장 방식 등
개발·운영 환경	서버·DB·네트워크·무선 네트워크	시스템 설정, 공개 취약점, 접근통제와 침해 흔적 등

홈페이지 하나만 운영한다면 웹 점검을, 앱과 API 서버를 함께 운영한다면 모바일 앱과 개발·운영 환경을 함께 상담하는 편이 좋습니다. 다만 신청했다고 모든 분야를 무조건 점검받는 것은 아니고, 적격성 검토와 수요에 따라 지원 범위가 정해집니다.

신청 전 준비할 자료와 실제 신청 순서

신청 전에 가장 먼저 해야 할 일은 ‘무엇을 점검받을지’ 정리하는 겁니다. 회사 대표 홈페이지 주소만 적는 것보다 실제 서비스 구조를 간단히 정리해두면 협의가 훨씬 수월해져요.

회사명과 사업자 정보
중소기업 확인을 위한 증빙 자료
점검할 홈페이지 주소와 관리자 페이지 주소
모바일 앱 이름, 운영체제, 배포 중인 앱 버전
서버·DB·클라우드 사용 여부와 운영 담당자 연락처
점검 중 서비스 중단이 가능한 시간대
테스트 계정 또는 점검에 필요한 접근 정보

실제 신청은 보호나라에서 정보보호 서비스 → 서비스 신청하기 → 기업 보안취약점 점검을 선택하는 흐름입니다. 서비스 목록에서 점검 항목을 고른 뒤 신청서를 제출하고, 이후 지원 대상 여부와 점검 자산·일정·방법을 협의하게 됩니다.

보호나라 서비스 신청하기

신청 절차는 보통 신청·접수, 적격성 검토, 지원방안 협의, 취약점 점검, 취약점 조치와 결과 회신 순서로 이어집니다. 점검일에는 개발자나 서버 관리자가 함께 있어야 질문에 바로 답할 수 있으니, 외주 개발사와 호스팅 업체의 담당자 연락처도 미리 준비해두는 게 좋습니다.

점검 결과를 받은 뒤 가장 먼저 고칠 것

취약점 목록을 받으면 항목이 많아서 어디부터 손대야 할지 막막할 수 있습니다. 이때 발견 개수보다 ‘외부 공격자가 바로 악용할 수 있는가’와 ‘개인정보나 관리자 권한으로 이어지는가’를 먼저 보세요.

1. 인터넷에 노출된 관리자 페이지와 원격 접속부터 줄이기

관리자 페이지, SSH, 원격 데스크톱, DB 관리 화면이 인터넷 전체에 열려 있다면 가장 먼저 접근을 제한해야 합니다. 허용 IP를 회사나 VPN으로 좁히고, 불필요한 포트와 서비스는 중지하는 방식입니다. 관리자 계정에는 긴 비밀번호와 다중인증을 적용하고, 여러 사람이 하나의 계정을 함께 쓰는 방식도 피해야 하고요.

2. 개인정보와 인증정보가 노출되는 경로 막기

화면에 보이지 않더라도 API 응답이나 오류 메시지, 백업 파일, 로그에 개인정보와 토큰이 남을 수 있습니다. 주민등록번호·결제정보 같은 민감한 정보는 꼭 필요한 만큼만 처리하고, 비밀번호는 복호화할 수 없는 방식으로 저장해야 합니다. 소스코드나 환경설정 파일에 API 키와 DB 비밀번호를 넣어둔 경우에는 키를 즉시 폐기하고 새로 발급하는 조치까지 필요합니다.

3. 파일 업로드와 입력값 검증 문제 고치기

홈페이지에서 파일을 업로드하거나 게시물을 등록할 수 있다면 확장자만 확인해서는 부족합니다. 허용 파일 형식을 제한하고, 업로드 폴더에서 파일이 실행되지 않게 분리하며, 파일명과 경로를 서버가 안전하게 처리해야 합니다. 검색창·로그인·주문·회원가입처럼 사용자가 값을 입력하는 기능은 서버 측에서도 검증해야 하죠.

4. 오래된 운영체제·웹서버·오픈소스 패치 적용하기

점검 결과에 CVE나 공개 취약점이 표시됐다면 해당 프로그램의 버전과 실제 사용 여부부터 확인합니다. 무조건 최신 버전을 바로 올리기보다는 백업과 테스트를 먼저 진행하고, 서비스 중단 가능 시간을 정해 패치하세요. 사용하지 않는 플러그인과 라이브러리는 삭제하는 편이 업데이트 부담도 줄여줍니다.

5. 서버 침해 흔적과 비정상 파일 확인하기

웹셸, 랜섬웨어, 비정상 관리자 로그인, 수상한 예약 작업이 발견됐다면 단순히 파일 하나를 지우는 것으로 끝내면 안 됩니다. 해당 서버를 격리하고 로그와 계정 접속 기록을 보존한 뒤 침해사고 대응 절차로 넘어가야 합니다. 이미 침해가 의심되는 상황이라면 일반 취약점 점검보다 사고 신고와 원인 분석이 먼저일 수 있어요.

홈페이지·앱·서버별 조치 포인트

같은 ‘보안 취약점’이라도 자산에 따라 고치는 방법이 달라집니다. 결과 보고서의 항목명을 그대로 개발자에게 전달하기보다는 아래처럼 실제 작업으로 바꿔보세요.

자산	자주 확인할 문제	조치 예시
홈페이지	관리자 노출, 파일 업로드, SQL 인젝션, 오류 메시지	접근제어 강화, 입력값 검증, 업로드 실행 차단, 오류정보 최소화
모바일 앱	앱 내 비밀번호·토큰 저장, 인증 우회, 변조 대응 부족	민감정보 저장 최소화, 서버 재검증, 인증서·토큰 관리 강화
서버·DB	미사용 계정, 약한 비밀번호, 불필요한 포트, 미패치 소프트웨어	계정 정리, 접근권한 최소화, 방화벽 제한, 보안 업데이트

특히 앱은 앱 화면만 고쳐서는 충분하지 않을 수 있습니다. 앱이 호출하는 API 서버에서 권한 검사를 제대로 하는지가 핵심이라서 모바일 앱 점검과 서버 점검 결과를 함께 봐야 합니다. SaaS 사업자라면 고객사별 데이터가 섞이지 않는지, 운영자 권한이 과도하지 않은지, 클라우드 저장소가 공개돼 있지 않은지도 별도로 확인해야 하고요.

조치가 끝났다면 재점검과 기록까지 남기기

취약점을 고친 뒤에는 개발자가 ‘수정 완료’라고 말하는 것만으로 마무리하지 않는 게 좋습니다. 어떤 항목을 언제, 어떤 방식으로 수정했는지 기록하고 다시 점검해 실제로 문제가 사라졌는지 확인해야 합니다.

취약점별 담당자와 조치 기한을 정합니다.
서비스 중단과 데이터 영향 여부를 확인한 뒤 수정합니다.
변경 전후 설정과 배포 버전을 기록합니다.
동일한 공격 경로가 재현되지 않는지 재점검합니다.
남은 위험은 수용·완화·추가 개선으로 구분합니다.

서버 중심의 지속적인 관리가 필요하다면 KISA의 ‘내 서버 돌보미’도 별도로 살펴볼 만합니다. 주요 WEB·WAS와 DB 서버를 대상으로 운영체제 설정, 공개 취약점, 침해 흔적 등을 점검하고, 조치 계획과 이행 여부 확인, 자가진단 도구 제공까지 이어지는 서비스입니다.

다만 KISA 점검 결과는 보안 강화를 위한 지원 자료이지, 모든 해킹 가능성이 사라졌다는 인증서나 안전 보증은 아닙니다. 서비스가 커지거나 개인정보와 결제가 연결돼 있다면 정기적인 취약점 진단, 소스코드 점검, 로그 모니터링, 백업 복구훈련까지 별도로 운영해야 합니다.

자주 묻는 질문

Q. 법인이나 직원이 적은 1인 사업자도 신청할 수 있나요?

A. 직원 수만으로 판단하는 서비스는 아니며, 중소기업기본법상 중소기업인지와 지원 대상 서비스에 해당하는지가 중요합니다. 신청 과정에서 중소기업 확인 자료를 요구받을 수 있으므로 관련 증빙을 준비해두는 편이 안전합니다.

Q. 홈페이지 점검을 받으면 소스코드까지 모두 검사하나요?

A. 일반 홈페이지 취약점 점검과 소스코드 정적 분석은 같은 서비스가 아닐 수 있습니다. 개발 중인 프로그램의 소스코드와 오픈소스 구성요소까지 확인하려면 별도의 SW 개발보안 또는 공급망 보안 진단 대상인지 상담해야 합니다.

Q. 점검 중 홈페이지가 중단될 수 있나요?

A. 점검 방식과 대상에 따라 달라질 수 있습니다. 신청 전에 운영 중인 서비스인지, 테스트 환경을 사용할 수 있는지, 허용 가능한 점검 시간대가 언제인지 전달해 점검 방안을 협의하는 것이 좋습니다.

Q. 취약점 결과가 나왔는데 당장 수정할 개발자가 없으면 어떻게 하나요?

A. 먼저 인터넷 노출 차단, 계정 잠금·비밀번호 변경, 취약 기능 임시 비활성화처럼 피해 가능성을 줄이는 조치를 진행하세요. 이후 외주 개발사나 전문 컨설턴트에게 결과 보고서의 항목과 재현 조건을 함께 전달해 수정 범위와 재점검 일정을 잡는 방식이 현실적입니다.

보안 점검은 신청서를 내고 결과표를 받는 데서 끝나는 일이 아니죠. 홈페이지·앱·서버 중 어떤 자산에서 문제가 발견됐는지 나눈 다음, 외부에 노출된 관리자 기능과 계정, 개인정보, 파일 업로드, 패치 문제부터 순서대로 줄여가면 됩니다. 작은 회사일수록 모든 항목을 한 번에 해결하려 하기보다 ‘지금 뚫리면 가장 큰 피해가 나는 것’부터 고치는 게 중요해요. 조치 기록과 재점검까지 남겨두면 다음 점검을 받을 때도 훨씬 수월합니다.