보안 코딩이란 무엇인가요?

보안 코딩은 보안 프로그래밍이라고도 하며, 사이버 공격을 수행하는 위협 행위자로부터 방어할 수 있는 소스 코드를 작성하는 관행입니다. 코드에 보안을 내재화하면 취약점을 줄이고, 사이버 위협에 견딜 수 있을 만큼 강력하고 복원력 있는 소프트웨어를 만들 수 있습니다.

보안 프로그래밍은 보안 소프트웨어 개발 수명 주기(SSDLC)의 중요한 구성 요소입니다. 보안이 테스트 단계에서만 고려되는 기존 SDLC와 달리, SSDLC는 소프트웨어 개발의 모든 단계에 사이버 보안을 통합합니다. 코드 보안은 단순한 사후 고려 사항이나 선택적 추가 기능 또는 별도의 요소가 아니라, 안전한 소프트웨어를 구축하기 위한 필수 요소입니다.

보안 코딩은 보다 넓은 범주의 애플리케이션 보안에 포함됩니다. 보안 프로그래밍이 코드에 사이버 보안을 통합하는 데 초점을 맞춘다면, 애플리케이션 보안은 하드웨어 보호부터 소프트웨어 기반 방어까지 다양한 보안 조치를 포함하며 SDLC 전반에 걸쳐 적용됩니다.

IBM의 2026년 X-Force Threat Intelligence Index에 따르면, 취약점 악용은 공격의 주요 원인이 되었습니다. 보안 코딩과 같은 보다 선제적이고 예방적인 접근 방식으로 전환하면 위협이 확대되기 전에 대응할 수 있습니다.

보안 프로그래밍은 다음과 같은 이점을 제공합니다.

• 비용 효율성: 배포 후보다 배포 전에 보안 결함을 수정하는 것이 비용이 더 적게 듭니다.

• 데이터 보안: 민감한 데이터 보호 조치를 소스 코드 수준에서 적용하여 데이터 보호 규정 준수를 지원합니다.

• 조기 탐지 및 예방: 개발 단계에서 취약점을 발견하고 제거하여 운영 환경으로 확산되는 것을 방지합니다.

• 시간 및 노력 절감: 보안 코드로 운영 시스템에서의 사고 대응 및 복구에 필요한 상당한 시간과 노력을 줄일 수 있습니다.

코드 내 보안 취약점은 일반적으로 소프트웨어 설계 및 아키텍처 결함, 잘못된 구성 또는 프로그래밍 오류 등에서 발생합니다. 악의적인 행위자는 이러한 취약점을 공격의 진입 지점으로 자주 악용합니다.

다음은 Open Worldwide Application Security Project(OWASP)의 웹 애플리케이션 보안 위험 목록을 기반으로 보안 프로그래밍이 해결하고자 하는 대표적인 취약점입니다.

• 인증 실패

• 접근 제어 결함

• 암호화 결함

• 인젝션 공격

• 취약한 설계

• 로깅 및 경고 실패

• 보안 구성 오류

• 소프트웨어 또는 데이터 무결성 실패

사이버 범죄자는 인증 메커니즘의 취약점을 악용해 사용자 자격 증명을 탈취하고 악의적인 활동을 수행합니다. 인증 실패에는 취약한 비밀번호 정책, 강력한 인증 방식의 부재, 부적절한 세션 관리, 그리고 무차별 대입 공격과 같이 시행착오를 통해 올바른 비밀번호를 찾거나 유출된 사용자 이름과 비밀번호 조합을 활용해 계정에 접근하는 크리덴셜 스터핑에 대한 보호 부족이 포함됩니다.

접근 제어는 누가 데이터나 리소스에 접근할 수 있는지, 그리고 어떤 작업을 수행할 수 있는지를 정의합니다. 접근 제어가 손상되었거나 잘못 적용되면 무단 접근 및 권한 남용으로 이어질 수 있습니다. 위협은 API 요청이나 URL 매개변수를 변경해 접근 제어 검사를 우회하거나, 권한 검증 없이 고유 식별자를 사용해 데이터나 리소스를 직접 참조할 수 있게 하는 안전하지 않은 직접 객체 참조를 포함할 수 있습니다.

암호화 방식의 결함은 민감한 데이터를 노출시키고 데이터 유출로 이어질 수 있습니다. 암호화 결함에는 오래되었거나 취약한 암호화 알고리즘, 부적절한 키 관리 프로토콜, 하드코딩된 키 사용, 그리고 적절한 암호화 없이 데이터를 전송하거나 저장하는 문제가 포함됩니다.

인젝션 공격은 가장 흔한 보안 취약점 유형 중 하나입니다. 코드, 명령어, 쿼리 또는 스크립트와 같은 악의적인 입력이 프로그램이나 웹 페이지에 삽입되어 악성 소프트웨어를 실행하거나 데이터를 변조하거나 개인정보를 탈취하는 등 다양한 악의적 행위를 수행합니다. 크로스 사이트 스크립팅, 크로스 사이트 요청 위조, 서버 측 요청 위조는 대표적인 인젝션 공격 유형입니다.

크로스 사이트 스크립팅(XSS)은 신뢰할 수 있는 웹사이트에 신뢰되지 않은 코드나 스크립트를 삽입하여, 이를 사용자가 인지하지 못한 상태에서 실행하도록 합니다. 이는 일반적으로 애플리케이션이 사용자 입력 데이터를 이스케이프 처리, 필터링, 정제 또는 검증하지 못할 때 발생합니다.

크로스 사이트 요청 위조(CSRF 또는 XSRF)는 인증된 사용자로부터 웹사이트에 무단 요청을 전송합니다. 이는 사이트가 인증된 사용자의 웹 브라우저를 신뢰한다는 점을 악용하여, 브라우저가 대상 사이트로 악성 요청을 보내도록 속이는 링크나 스크립트를 사용합니다.

서버 측 요청 위조(SSRF)는 서버로 전송되는 URL을 조작합니다. 서버가 URL을 검증하지 않은 채 조작된 요청을 처리하면, 해당 요청을 통해 데이터베이스와 같은 내부 서비스에 연결하거나 파일, 서버 구성 및 기타 메타데이터를 읽을 수 있습니다.

취약한 설계는 비즈니스 로직 또는 애플리케이션 아키텍처의 결함으로 인해 발생하는 취약점을 의미합니다. 이는 요구 사항을 정의하고 시스템 설계를 구상하는 SDLC의 계획 단계 초기에 발생합니다. 위험 평가 부족, 보안 설계 패턴 및 참조 아키텍처의 제한적 사용, 그리고 계획된 아키텍처의 잠재적 보안 취약점을 체계적으로 분석하기 위한 위협 모델링의 부족 등이 모두 취약한 설계의 원인이 될 수 있습니다.

부적절하거나 비효율적인 경고 및 로그는 공격과 침해를 감지하지 못하게 하여 위협 행위자가 심각한 피해를 초래할 수 있습니다. 로깅 및 경고 실패의 예로는 중요한 이벤트가 기록되지 않거나 일관되지 않게 기록되는 경우, 변조나 무단 접근에 취약한 안전하지 않은 로그 저장소, 실시간 또는 준실시간 공격에 대한 경고 부족, 불명확하거나 세부 정보 또는 컨텍스트가 부족한 로그 메시지, 그리고 마스킹이나 제거 없이 민감한 데이터를 포함한 로그 등이 있습니다.

이 취약점은 클라우드 서비스, 데이터베이스, 프레임워크, 라이브러리, 운영 체제, 웹 서버를 포함한 애플리케이션 스택의 보안 설정이 올바르게 구성되지 않을 때 발생합니다. 보안 구성 오류에는 비활성화된 보안 업데이트, 과도하게 넓은 권한, 변경되지 않은 기본 자격 증명, 불필요하게 활성화된 기능 등이 포함됩니다.

이러한 문제는 외부에서 들어오는 유효하지 않거나 신뢰할 수 없는 데이터를 수용하거나 처리하는 것을 방지하는 보호 장치의 부족과 관련이 있습니다. 예로는 무결성 검증 없이 소프트웨어 업데이트를 자동으로 적용하는 경우, 타사 라이브러리 및 플러그인과 같은 의존성을 신뢰할 수 없는 출처에서 사용하는 경우, 그리고 검증 없이 코드나 기타 소프트웨어 개발 산출물을 가져오는 CI/CD 파이프라인이 있습니다.

일부 생성형 AI 기술은 보안 프로그래밍에 도움을 줄 수 있습니다. 예를 들어 Claude Code 및 IBM Bob와 같은 에이전틱 AI 코딩 플랫폼은 취약점을 식별하고 안전하지 않은 코드에 대한 수정 방안을 실시간으로 제안할 수 있습니다. AI 코드 생성 툴은 보안을 강화하기 위한 코드 리팩토링에도 도움을 줄 수 있습니다.

이러한 툴은 소프트웨어 개발을 자동화하고 속도를 높일 수 있지만, 안전한 코드를 생성하려면 여전히 명확한 지침이 필요합니다. 프로그래머는 기능뿐만 아니라 보안 요구 사항도 명확히 지정하는 프롬프트를 제공해야 합니다. 예를 들어 “로그인 기능 생성”과 같은 일반적인 프롬프트는 “사용자 입력이 예상된 형식과 길이를 충족하는지 확인하는 로그인 기능 생성”으로 확장하여 보안 코딩 지침을 포함할 수 있습니다. Open Source Security Foundation 가이드에는 AI 어시스턴트가 코드 보안을 고려할 수 있도록 돕는 샘플 지침이 포함되어 있습니다.

소프트웨어 엔지니어링 팀은 생성형 AI가 더 안전한 코드를 생성하도록 유도하는 컨텍스트를 제공할 수도 있습니다. 검색 증강 생성(RAG)은 AI 기반 개발자 툴을 내부 보안 코딩 표준과 연결합니다. 명확한 가이드라인이 없는 팀의 경우 Secure Code Warrior의 AI 보안 규칙이 더 안전한 AI 생성 코드의 출발점이 될 수 있습니다.

AI 어시스턴트와 마찬가지로 AI 코딩 에이전트도 지침의 도움을 받습니다. Project CodeGuard는 보안 코딩 관행을 에이전틱 워크플로에 직접 내재화하는 규칙 세트와 역량 프레임워크를 제공합니다. AI 코딩 에이전트는 이러한 규칙과 역량을 계획 단계에서 목표의 일부로 활용하고, 코드 작성 과정인 실행 단계에서도 이를 적용할 수 있습니다.

인공지능이 생성한 코드 자체도 취약점을 포함할 수 있으므로, 정확성과 안전성에 대한 최종 판단은 여전히 인간 프로그래머의 몫입니다. 생성형 AI 활용 방식은 아래의 보안 코딩 모범 사례와 함께 적용되어야 하며, 이를 통해 다층적인 보호 체계를 구축할 수 있습니다.

보안 코딩의 모범 사례는 소프트웨어 보안을 강화하기 위한 다양한 방어적 프로그래밍 전략을 포함합니다. 기업은 보안 코딩과 개발 속도 간의 균형에 대해 우려할 수 있습니다. 그러나 이러한 많은 관행은 설계 단계에 보안을 통합하고, 보안 코딩 가이드라인을 수립하며, 개발자가 코딩 중에 보안 결함을 식별하고 수정할 수 있도록 교육하고, 취약점을 탐지하기 위해 코드 분석과 테스트를 자동화하는 방식으로 빠른 개발 속도를 유지하면서도 보안을 코드에 통합합니다.

모든 보안 코딩 모범 사례를 나열할 수는 없지만, 이 목록은 출발점이 되며 이러한 관행을 결합하면 조직의 보안 태세를 강화할 수 있습니다.

• 보안 코딩 표준 준수

• 설계 단계에 보안 통합

• 입력값 검증 및 정제, 출력값 인코딩

• 강력한 암호화 프로토콜 구현

• 인증 및 권한 부여

• 강력한 로깅 및 안전한 오류 처리 메커니즘 구축

• 철저한 보안 테스트 수행

• 코드 리뷰에 보안 요소 포함

이러한 표준은 기존 개발 워크플로에 보안 코딩 기법을 효과적으로 통합하기 위한 기본 지침 역할을 합니다. 또한 소프트웨어 프로젝트 전반에 걸쳐 보안 프로그래밍을 위한 공통 기준을 제공합니다.

OWASP 개발자 가이드는 프로그래머가 안전한 소스 코드를 작성하고 활용할 수 있도록 돕는 참고 자료입니다. 이 가이드는 기술에 구애받지 않는 보안 코딩 관행을 제시하며, 주요 코드 보안 항목은 아카이브된 OWASP Secure Coding Practices Quick Reference Guide에서 이전된 체크리스트로 강조됩니다.

OWASP는 보안 코딩 원칙을 구현하고 다양한 코드 취약점에 대응할 수 있도록 치트 시트 모음도 제공합니다.

Carnegie Mellon University의 Software Engineering Institute에서 개발한 SEI CERT Coding Standards는 Android, C, C++, Java, Perl 프로그래밍 언어에서의 보안 프로그래밍 지침을 제공합니다. 이 표준에는 규칙, 권장 사항, 그리고 준수 및 비준수 코드 예제가 포함되어 있습니다. 각 규칙과 권장 사항에는 심각도, 발생 가능성, 수정 비용에 따라 분류된 위험 평가가 포함되어 있어 소프트웨어 엔지니어링 팀이 우선순위를 정하는 데 도움을 줍니다.

정보 보안 및 사이버 보안 위험 관리를 위한 Cybersecurity Framework와 함께, National Institute of Standards and Technology(NIST)는 Secure Software Development Framework도 발표했습니다. 이 프레임워크는 결과 중심의 고수준 보안 소프트웨어 개발 관행으로 구성되어 있으며, OWASP와 SEI CERT의 보다 기술적인 표준을 보완하는 데 적합합니다.

시스템 설계 단계에서 보안을 반영하는 것은 소프트웨어 개발 과정에서 보안을 앞단으로 이동시키는 “shift left” 접근 방식과 일치합니다. 이는 첫 줄의 코드가 작성되기 전부터 소프트웨어를 안전하게 만드는 방법을 고려합니다.

포괄적인 위험 평가와 위협 모델링은 소프트웨어 아키텍처의 잠재적 보안 취약점을 식별하는 데 도움을 줄 수 있습니다. 보안 설계 단계에서는 보안 팀이 참여하여 실무 협업을 수행하고, 보안 요구 사항과 이를 소스 코드 수준에서 처리하는 방법에 대한 지침을 제공해야 합니다.

설계에 보안을 통합하는 방법에 대한 자세한 내용은 OWASP의 보안 제품 설계 및 위협 모델링 치트 시트와 Secure by Design Framework를 참고할 수 있습니다.

보안 코딩의 핵심 원칙 중 하나는 인젝션 공격 사례에서 볼 수 있듯이 어떤 입력도 신뢰하지 않는 것입니다. 서버 측 검증과 정제는 입력이 처리되기 전에 보안 위험이 없도록 보장하는 데 도움을 줍니다.

소프트웨어 엔지니어링 팀은 모든 검증 및 정제 로직을 안전한 중앙 파일이나 위치에 배치하여 일관성을 유지하고 빠르고 쉽게 접근 및 업데이트할 수 있도록 할 수 있습니다. 또한 프로그래밍 언어와 프레임워크에 내장된 검증 및 정제 모듈을 사용할 수 있지만, 새롭게 발견되는 취약점에 대응하기 위해 정기적으로 업데이트해야 합니다.

입력 검증은 데이터 유형, 형식, 길이, 범위, 크기 및 기타 제약 조건이 올바른지 확인합니다. 이는 입력값을 승인된 패턴과 일치시키거나 허용된 문자 또는 값 집합과 비교하는 작업을 포함할 수 있습니다.

입력 정제는 데이터를 정리하고 안전한 형태로 변환하는 것을 의미합니다. 이는 사용하는 프로그래밍 언어나 프레임워크에 맞게 적용되어야 합니다.

예를 들어 HTML에서는 &, <, >, “, ‘와 같은 특수 문자를 이스케이프 처리하여 XSS를 방지할 수 있습니다. DOMPurify와 같은 라이브러리는 HTML 정제에 도움을 줄 수 있습니다.

데이터베이스에서는 매개변수화된 쿼리와 준비된 문을 함께 사용하면 입력이 실행 가능한 SQL 코드가 아니라 데이터로 처리되므로 SQL 인젝션 공격을 방지할 수 있습니다. 매개변수화된 쿼리는 먼저 모든 SQL 코드를 정의하고 입력값 또는 매개변수를 위한 자리표시자를 설정한 후, 각 매개변수를 나중에 쿼리에 전달합니다. 준비된 문은 사전 컴파일된 SQL 문으로, 삽입된 SQL 명령이 쿼리의 의도나 실행 방식을 변경할 수 없습니다.

출력 인코딩은 데이터가 코드로 해석되지 않도록 안전한 텍스트 형태로 표시되게 합니다. 많은 프레임워크는 기본 출력 인코딩 보호 기능이나 자동 인코딩 및 이스케이프 기능을 제공합니다. OWASP Java Encoder는 URL, 인라인 CSS 또는 인라인 JavaScript에 변수를 삽입하거나 HTML 속성 값, CSS 속성, 두 HTML 태그 사이에 변수를 넣는 등 다양한 컨텍스트에 맞는 출력 인코딩을 지원합니다.

암호화를 올바르게 적용하면 정보의 기밀성, 무결성 및 가용성을 보호할 수 있습니다.

프로그래머는 전송 중 및 저장된 데이터를 암호화할 때 최신의 강력한 알고리즘을 사용해야 합니다. AES는 대칭 암호화의 표준으로 간주되며, 인증 모드와 256비트 키를 사용하면 높은 수준의 보안을 제공합니다. 비대칭 암호화에서는 안전한 곡선을 사용하는 ECC 또는 무작위 패딩이 적용된 RSA(최소 2048비트 키)가 강력한 보안을 제공합니다.

비밀번호를 보호하기 위해서는 해싱 알고리즘을 적용하고, 해싱 과정의 일부로 고유한 무작위 문자열인 솔트를 추가해야 합니다. 해싱 알고리즘은 데이터를 고유하고 더 짧으며 고정된 길이의 값으로 변환하는 단방향 수학 함수로, 이를 해독하거나 역으로 되돌릴 수 없습니다. 최신 해싱 알고리즘에는 Argon2id와 scrypt가 포함됩니다.

개발자는 자체 구현을 만드는 대신 Bouncy Castle, Libsodium, OpenSSL, Tink과 같은 신뢰할 수 있고 지원 및 유지 관리되는 암호화 라이브러리를 사용해야 합니다.

키는 소스 코드에 하드코딩되거나 버전 관리 시스템에 포함되거나 환경 변수에 저장되거나 로그에 노출되어서는 안 됩니다. 키 관리 솔루션과 기술은 생성, 배포, 저장부터 사용, 교체, 폐기, 삭제까지 키 관리 라이프사이클을 자동화하는 데 도움을 줍니다.

전송 계층 보호를 위해 소프트웨어 엔지니어링 팀은 HTTPS 또는 HTTP Strict Transport Security(HSTS)와 같은 프로토콜과 최신 버전의 TLS를 사용해야 합니다. 민감한 데이터의 캐싱은 비활성화해야 하며, 불필요한 저장은 피해야 합니다.

인증 및 권한 부여는 엔티티의 신원을 확인하고 적절한 수준의 접근 권한을 보장하기 위한 핵심 보안 코딩 관행입니다.

다중 요소 인증(MFA)은 비밀번호 관련 공격에 대한 가장 효과적인 방어 수단 중 하나입니다. 그 밖의 방법으로는 해커가 비밀번호를 반복적으로 추측하지 못하도록 로그인 시도를 제한하는 기능과, 일정 횟수 이상 로그인에 실패했을 경우 일정 시간 동안 로그인 시도를 차단하는 계정 잠금 기능이 있습니다.

비밀번호 없는 인증을 위해 개발자는 OpenID Connect(OIDC) 및 Security Assertion Markup Language(SAML)와 같은 프로토콜을 고려할 수 있습니다. FIDO 및 FIDO2 오픈 표준은 패스키를 통한 비밀번호 없는 인증을 지원하며, 애플리케이션, 온라인 서비스 및 웹사이트 인증에 활용할 수 있습니다.

인증된 세션이 설정된 이후에는 안전한 세션 ID 또는 토큰을 통해 이를 유지해야 합니다. 세션 ID는 강력한 암호학적으로 안전한 의사 난수 생성기를 사용해 생성해야 합니다. 다른 사용자 입력과 마찬가지로 세션 ID 또는 토큰도 처리 전에 검증해야 하며, 유효하지 않은 값은 필터링해야 합니다.

각 세션에 만료 시간을 설정하면 악의적인 행위자가 활성 세션을 탈취해 공격을 수행할 수 있는 시간을 제한할 수 있습니다. 소프트웨어 엔지니어링 팀은 웹 개발 프레임워크에서 제공하는 내장 세션 관리 기능을 활용할 수 있습니다.

프로그래머는 OIDC 인증 프로토콜과 함께 작동하는 OAuth와 같은 권한 부여 프로토콜을 사용할 수 있습니다. 접근 제어 측면에서는 역할 기반 접근 제어(RBAC)가 널리 사용되며, 사용자에게 사전에 정의된 역할에 따라 접근 권한이 부여됩니다. 보다 강력하고 세분화된 권한 관리를 지원하는 방식으로는 속성 기반 접근 제어(ABAC)와 관계 기반 접근 제어(ReBAC)가 있습니다. ABAC는 사용자 이름, 리소스 유형, 시간대와 같은 사용자, 객체, 행위의 속성을 분석하여 접근 허용 여부를 결정합니다. ReBAC는 리소스 간의 관계를 기반으로 접근 권한을 부여합니다.

프로토콜과 접근 제어 모델이 적용되어 있더라도, 모든 요청마다 권한을 검증하고 엔티티가 접근하려는 각 객체에 대해 접근 제어 검사를 수행해야 합니다. 기본적으로 접근을 거부하고 최소 권한 원칙을 적용하는 것도 권한 부여 측면에서 중요한 보안 코딩 원칙입니다.

로그와 오류 메시지는 공격을 계획하는 데 악의적인 행위자에게 유용한 정보가 될 수 있습니다. 따라서 로그와 오류는 모두 신중하게 처리해야 합니다.

애플리케이션 오류, 구성 변경 및 관리자 또는 권한 있는 작업과 관련된 시스템 이벤트, 그리고 인증, 권한 부여, 입력 검증, 세션 관리 영역에서의 실패 이벤트는 모두 기록해야 하며, 이는 침해 시도를 나타낼 수 있기 때문입니다. 분석 및 디버깅을 지원하기 위해 사용자 세부 정보(신원, 역할, 권한)와 오류 또는 이벤트의 컨텍스트(대상, 작업, 결과)와 같은 충분한 정보가 포함되어야 합니다.

로그는 읽기 전용 매체에 기록하고, 접근이 제한되며 변조 감지 기능이 포함된 안전한 위치에 저장해야 합니다. 로그를 다른 시스템으로 전송해야 하는 경우에는 안전한 전송 프로토콜을 사용해야 합니다.

민감한 데이터는 로그에 기록해서는 안 되며, 로그에서 제거하거나 삭제해야 합니다. 데이터베이스 연결 문자열, 파일 경로, 내부 네트워크 이름 및 주소, 세션 ID 또는 토큰과 같이 중요하다고 판단되는 기타 정보는 암호화, 해싱 또는 마스킹 처리해야 합니다.

로깅 라이브러리는 보안 취약점이 패치되도록 주기적으로 업데이트해야 하며, 이는 널리 사용되는 오픈 소스 Log4j 로깅 라이브러리에 영향을 미쳐 공격자가 영향을 받는 시스템에서 거의 모든 코드를 실행할 수 있게 한 Log4Shell 취약점 사례에서도 확인할 수 있습니다.

오류 처리는 오류 정보가 일반적으로 로그에 기록되기 때문에 로깅과 밀접하게 연관되어 있습니다. 또한 처리되지 않은 오류는 위협 행위자의 침입 경로가 될 수 있습니다.

개발자는 예기치 않은 오류에 대해 일반적인 응답 또는 오류 코드를 반환하고, 서버 측에서 보다 자세한 오류 정보를 기록하는 전역 오류 처리기를 구현하는 것을 고려할 수 있습니다. 이 방식은 오류를 안전하게 처리하면서 해커에게 정보가 노출되는 것을 방지하고, 개발자가 추가로 분석할 수 있는 필요한 정보를 제공합니다.

소스 코드에 내재된 모든 보안 조치는 반드시 검증되어야 합니다. QA 및 개발 팀은 코드 보안 테스트의 기준으로 OWASP의 Web Security Testing Guide와 Application Security Verification Standard를 참고할 수 있습니다. 자동화된 툴도 이 과정에 도움을 줄 수 있습니다.

정적 애플리케이션 보안 테스트(SAST)는 사전에 정의된 규칙을 적용해 코드 내에서 취약점을 나타낼 가능성이 있는 패턴을 식별합니다. SAST는 “화이트 박스” 테스트라고도 불리며, 애플리케이션을 실행하지 않고 코드를 분석하기 때문에 SAST 툴은 정적 코드 분석기라고도 합니다.

SAST 툴은 일반적인 코드 취약점을 효과적으로 식별하며, 발견된 취약점의 정확한 라인 번호와 파일 위치를 파악할 수 있습니다. 또한 대부분의 IDE 및 CI/CD 환경과 원활하게 통합됩니다. 하지만 오탐이 발생할 가능성이 있습니다.

동적 애플리케이션 보안 테스트(DAST)는 외부에서 내부로 접근하는 방식으로, 실제 위협 행위자의 행동을 모방한 시뮬레이션 공격을 통해 실행 환경에서 애플리케이션을 평가합니다. 이 때문에 DAST는 테스트자가 시스템의 내부 구조나 소스 코드에 대한 지식이나 접근 없이도 수행할 수 있어 블랙 박스 테스트라고도 합니다. DAST는 일반적으로 SAST보다 오탐률이 낮습니다.

SAST와 DAST를 함께 활용하면 잠재적 취약점에 대한 보다 종합적인 파악이 가능합니다. 보다 포괄적인 보안 테스트를 위해 SAST와 DAST는 코드 컨텍스트와 실행 동작을 함께 분석하여 실시간으로 취약점을 보고하는 대화형 애플리케이션 보안 테스트(IAST)와, 소프트웨어 구성 요소가 안전하고 최신 상태인지 분석하는 소프트웨어 구성 분석(SCA)과 같은 방법과 함께 사용할 수 있습니다.

대부분의 코드 리뷰는 스타일 가이드 준수, 논리적 문제, 최적의 흐름, 테스트 및 엣지 케이스 커버리지를 검토하는 등 품질에 중점을 둡니다. 그러나 보안 역시 코드 리뷰 과정에 포함되어야 합니다.

보안 코드 리뷰는 정적 코드 분석기 다음 단계의 방어선 역할을 합니다. 사람이 수행하는 코드 리뷰는 자동화된 툴이 놓치기 쉬운 코드 보안 취약점에 대해 도메인 전문성, 판단력, 통찰력을 제공합니다.

보다 체계적인 접근을 위해 코드 리뷰어는 OWASP 보안 코드 리뷰 치트 시트를 참고할 수 있습니다.