소스코드 보안 진단 가이드
시큐어코딩 보안약점 점검

왜 소스코드 진단이 의무가 되었나

공공부문은 일정 규모 이상의 정보화사업에 소프트웨어 개발보안(시큐어코딩) 적용이 의무입니다. 사업 종료 시 진단을 수행하고 발견된 보안약점을 제거해야 검수가 완료됩니다.

금융권은 전자금융 관련 감독기준의 정보처리시스템 보호대책과 취약점 평가가 근거가 되고, 개인정보를 처리하는 시스템이라면 개인정보 보호 법령의 접근통제·암호화 요구가 함께 적용됩니다.

보안약점의 7개 유형

국내 개발보안 기준은 구현 단계에서 제거해야 할 보안약점을 아래 일곱 가지 유형으로 나눕니다. 유형을 알면 발견사항이 개별 실수인지 설계 차원의 공백인지 구분할 수 있습니다. 같은 유형이 여러 파일에서 반복된다면 개발자 개인이 아니라 프로세스를 고쳐야 한다는 신호입니다.

정적 진단과 동적 진단의 관계

공공기관 홈페이지 진단 과업은 대개 표준 웹 취약점 점검항목 체계로 보고서를 요구합니다. 이 체계는 실행 중인 웹 애플리케이션을 대상으로 하는 동적 진단 관점이고, 개발보안 기준의 보안약점은 소스코드를 대상으로 하는 정적 진단 관점입니다.

같은 취약점이라도 접근 방식이 다릅니다. 예를 들어 SQL 인젝션은 동적 진단에서는 “페이로드를 넣었더니 오류가 났다”로, 정적 진단에서는 “42행에서 파라미터가 문자열 연결로 질의문에 들어간다”로 확인됩니다. 정적 진단은 도달 경로 전체를 볼 수 있어 누락이 적고, 동적 진단은 실제 악용 가능성을 입증합니다.두 진단은 대체 관계가 아니라 보완 관계입니다.

진단의 승부처는 오탐 제거다

정적 진단 도구가 신뢰를 잃는 이유는 거의 항상 오탐입니다. 수백 건이 쏟아지면 개발팀은 전부 무시하게 되고, 그 안에 섞인 진짜 취약점도 함께 묻힙니다. 위험한 함수가 쓰였다는 사실만으로 취약점이 되지는 않습니다.외부 입력이 그 지점에 실제로 도달하는지, 프레임워크나 라이브러리가 이미 막고 있지는 않은지까지 확인해야 발견사항으로 성립합니다.

확정할 수 있는 것과 판단이 필요한 것을 나눈다

자격증명이 코드에 박혀 있거나 안전하지 않은 암호 알고리즘을 쓴 경우는코드에 존재한다는 사실만으로 기준 위반이 확정됩니다. 반면 주입 계열 취약점은 외부 입력의 도달 여부에 성립이 달려 있어 경로를 함께 확인해야 합니다. 진단 결과에는 이 둘을 구분해 확신도를 표기하고 근거를 제시해야 개발팀이 반박이 아니라 조치로 응답합니다.

취약점만 보면 절반만 본 것이다

정적 진단 도구는 잘못 쓴 코드를 찾습니다. 그런데 감사에서 문제가 되는 것은 대부분 있어야 하는데 없는 코드입니다.

개인정보를 조회하는 화면이 이력을 남기지 않는다고 해서 공격자가 그것을 악용하지는 않습니다. 하지만 유출 사고가 났을 때 누가 언제 무엇을 조회했는지 증명할 수 없고, 그 순간 “통제가 없었다”는 결론으로 이어집니다. 보유기간이 지난 개인정보를 파기하는 배치가 없는 것, 권한 검증이 화면에만 있고 서버에는 없는 것, 결제 금액을 클라이언트가 보낸 값 그대로 처리하는 것도 마찬가지입니다.

오픈소스 컴포넌트·라이선스 검토

직접 작성한 코드가 안전해도 가져다 쓴 라이브러리가 취약하면 시스템은 취약합니다. Log4Shell처럼 단일 컴포넌트가 전 산업에 영향을 준 사례가 이를 보여줍니다. 금융권 오픈소스 관리 기준은 대체로 아래 단계를 권고합니다.

라이선스 의무 — 소스 공개 의무가 어디서 생기는가

감사인이 진단 결과를 쓰는 순서

Verit Audit

소스 파일을 올리면 보안약점을 진단합니다

문제가 되는 파일과 라인, 왜 문제인지, 어떻게 고치는지를 함께 제시하고 자체 검증 절차로 오탐을 걸러냅니다. 코드에 박힌 비밀정보는 AI 전송 전에 서버에서 값을 치환하므로 값 자체는 외부로 나가지 않습니다.