연락처 정보
 기간 21 시간

코스 개요

A01:2025 – Broken Access Control (접근 제어 실패)

접근 제어는 사용자가 의도된 권한 범위 밖에서 행동을 하지 못하도록 정책을 강제합니다. 이 제어의 실패는 일반적으로 정보의 무단 유출, 모든 데이터의 수정 또는 파괴, 또는 사용자의 제한을 벗어난 비즈니스 기능 수행으로 이어집니다.

실무적 측면

  • 접근 제어 실패의 실제 사례

  • 안전한 접근 제어 및 모범 사례

A02:2025 – Security Misconfiguration (보안 설정 오류)

보안 설정 오류란 시스템, 애플리케이션 또는 클라우드 서비스가 보안 관점에서 올바르게 설정되지 않아 취약점이 생성되는 상태를 말합니다.

실무적 측면

  • 설정 오류의 실제 사례

  • 구성 관리 및 자동화 도구를 포함한 설정 오류 방지 단계

A03:2025 – Software Supply Chain Failures (소프트웨어 공급망 실패)

소프트웨어 공급망 실패는 소프트웨어의 빌드, 배포 또는 업데이트 프로세스에서 발생하는 중단 또는 기타 침해 사건입니다. 이는 시스템이 의존하는 서드파티 코드, 도구 또는 기타 의존성 내의 취약점이나 악성 변경으로 인해 흔히 발생합니다.

A04:2025 – Cryptographic Failures (암호화 실패)

일반적으로 전송 중인 모든 데이터는 전송 계층(OSI 4계층)에서 암호화되어야 합니다. CPU 성능이나 개인 키/서명 관리와 같은 과거의 장애물은 이제 암호화를 가속화하도록 설계된 명령어(예: AES 지원)를 갖춘 CPU와, LetsEncrypt.org와 같은 서비스를 통해 단순화된 개인 키 및 서명 관리, 그리고 주요 클라우드 벤더가 제공하는 특정 플랫폼에 더 긴밀하게 통합된 서명 관리 서비스에 의해 해결되었습니다.

전송 계층의 보안을 강화하는 것 외에도, 휴면 상태(at rest)로 저장되는 데이터 중 어떤 것이 암호화가 필요한지, 그리고 전송 중(애플리케이션 계층, OSI 7계층) 추가로 암호화가 필요한 데이터가 무엇인지 결정하는 것이 중요합니다.

예를 들어, 비밀번호, 신용카드 번호, 건강 기록, 개인 정보 및 기밀 정보는 특히 EU의 일반 데이터 보호 규정(GDPR)이나 PCI 데이터 보안 표준(PCI DSS)과 같은 개인정보 보호 법이나 규정에 해당되는 경우 추가적인 보호가 필요합니다.

실무적 측면

  • 약한 암호화 알고리즘이나 부적절한 키 관리와 같은 암호화 실패에 대한 상세 분석

  • 강력한 암호화 메커니즘, 안전한 프로토콜(SSL/TLS)의 중요성 및 웹 보안에서 현대 암호화의 사례

A05:2025 – Injection (주입)

주입 취약점은 공격자가 악성 코드나 명령어(SQL 또는 셸 코드 등)를 프로그램의 입력 필드에 삽입하여 시스템이 이를 시스템의 일부인 것처럼 실행하도록 속이는 시스템 결함입니다. 이는 참으로 심각한 결과를 초래할 수 있습니다.

실무적 측면

  • SQL, NoSQL, OS, LDAP 주입에 대한 상세 분석

  • 준비된 문법, 매개변수화된 쿼리, 입력 이스케이핑을 이용한 완화 기술

A06:2025 – Insecure Design (안전하지 않은 설계)

안전하지 않은 설계는 "없거나 비효율적인 제어 설계"로 표현되는 다양한 약점을 포괄하는 넓은 범주입니다.

안전하지 않은 설계는 Top Ten 위험 범주의 모든 원인이 되는 것은 아닙니다. 안전하지 않은 설계와 안전하지 않은 구현 사이에는 차이가 있다는 점에 유의하세요. 우리는 고의로 설계 결함과 구현 결함을 구분합니다. 그 이유는 두 가지의 근본 원인, 개발 프로세스에서의 발생 시점, 그리고 시정 조치가 다르기 때문입니다.

안전한 설계조차도 취약점으로 이어질 수 있는 구현 결함을 포함할 수 있습니다. 반면, 안전하지 않은 설계는 완벽한 구현으로도 수정할 수 없으며, 이는 특정 공격에 대항하기 위해 필요한 보안 제어가 생성되지 않았기 때문입니다.

안전하지 않은 설계에 기여하는 요인 중 하나는 개발 중인 소프트웨어 또는 시스템에 내재된 비즈니스 리스크 프로파일링의 부재이며, 이로 인해 필요한 보안 설계 수준을 결정하지 못하게 됩니다.

실무적 측면

  • 부적절한 입력 검증과 같은 취약점으로 이어질 수 있는 설계 결함을 탐색합니다.

  • 안전한 아키텍처 및 안전한 설계 원칙에 대한 전략을 연구합니다.

A07:2025 – Authentication Failures (인증 실패)

공격자가 무효하거나 잘못된 사용자를 합법적인 사용자로 인식하도록 시스템을 속일 수 있을 때 이 취약점이 존재합니다.

실무적 측면

  • 일반적인 인증 문제

  • 다중 요소 인증 및 적절한 세션 처리와 같은 안전한 인증 전략

A08:2025 – Software or Data Integrity Failures (소프트웨어 또는 데이터 무결성 실패)

소프트웨어 및 데이터 무결성 실패는 신뢰할 수 없거나 신뢰할 수 없는 코드 또는 데이터가 신뢰할 수 있고 유효한 것으로 처리되는 것을 방지하지 못하는 코드와 인프라와 관련이 있습니다.

이러한 예로는 애플리케이션이 신뢰할 수 없는 출처, 리포지토리, 콘텐츠 전송 네트워크(CDN)의 플러그인, 라이브러리 또는 모듈에 의존하는 경우가 있습니다.

소프트웨어 무결성 검사 없이 소비하고 제공하는 불안전한 CI/CD 파이프라인은 무단 접근, 안전하지 않거나 악성 코드, 또는 시스템 침해의 가능성을 도입할 수 있습니다.

또 다른 예시는 신뢰할 수 없는 장소에서 코드 또는 아티팩트를 가져오거나, 사용 전(서명 확인 또는 유사한 메커니즘을 통해) 검증하지 않는 CI/CD입니다.

실무적 측면

  • 신뢰할 수 없는 소프트웨어 업데이트 및 데이터 변조와 같은 이슈에 초점

  • 안전한 업데이트 메커니즘 및 데이터 무결성 검사

A09:2025 – Security Logging and Alerting Failures (보안 로깅 및 알림 실패)

로깅과 모니터링이 없으면 공격과 침해 사항을 감지할 수 없으며, 알림이 없으면 보안 사고 발생 시 빠르고 효과적인 대응이 매우 어렵습니다.

적극적인 반응을 시작하기 위한 로깅, 지속적 모니터링, 감지, 알림의 부족은 언제든지 발생할 수 있습니다.

실무적 측면

  • 보안 관련 정보 로깅 및 의심스러운 활동 모니터링의 중요성

  • 초기 침해 사항을 감지하기 위한 적절한 로깅 및 실시간 모니터링을 위한 도구 및 관행

A10:2025 – Mishandling of Exceptional Conditions (예외 상황 처리 실패)

소프트웨어에서 예외 상황을 잘못 처리한다는 것은 프로그램이 비정상적이고 예측할 수 없는 상황을 방지, 감지 및 반응하지 못하여 충돌, 예상치 못한 동작, 그리고 때로는 취약점으로 이어지는 것을 의미합니다.

이것은 다음 3가지 실패 중 하나 또는 여러 가지를 포함할 수 있습니다:

  • 애플리케이션이 비정상적인 상황이 발생하도록 방지하지 못함

  • 상황이 발생하는 동안 그것을 식별하지 못함

  • 상황 이후에 상황이 발생하면 그에 대해 잘 반응하지 않거나 반응하지 않음

SAST – 정적 응용 프로그램 보안 테스트

  1. 정적 분석이란 무엇이며 SDLC(Software Development Life Cycle)에서 언제 실행해야 하는지 (Shift Left)

  2. SAST를 통해 감지할 수 있는 취약점 유형, 취약한 코드 대 안전한 코드

  3. SAST 도구 개요 (예: Semgrep, SonarQube, Checkmarx, 클라이언트 스택에 따라 다름)

  4. 실습: 의도적으로 도입된 취약점이 있는 리포지토리에서 SAST 스캔 실행, 결과 해석, 위양성 대 실제 취약점 분류

DAST – 동적 응용 프로그램 보안 테스트

  1. SAST와 DAST의 차이, 실행 중인 애플리케이션에 대한 블랙박스 테스트

  2. DAST 스캔 흐름, 크롤링, 퍼징, 응답 분석

  3. DAST 도구 개요 (예: OWASP ZAP, Burp Suite)

  4. 실습: 취약한 테스트 애플리케이션(예: OWASP Juice Shop)에서 DAST 스캔 실행, 결과 식별 및 검증

SCA – 소프트웨어 구성 요소 분석

  1. 서드파티 의존성 및 라이브러리의 리스크, 상속된 취약점

  2. SBOM(소프트웨어 소재 목록)이란 무엇이며 왜 중요한지

  3. SCA 도구 개요 (예: Dependency Check, Snyk, GitHub Dependabot)

  4. 실습: 실제 프로젝트에서 SCA 스캔 실행, 취약한 의존성 식별 및 시정 계획 수립(업데이트, 패치, 완화)

요건

참가자는 다음과 같은 사항을 갖추어야 합니다:

  • 소프트웨어 개발 개념에 대한 기본 지식
  • 웹 애플리케이션 및 일반적인 웹 기술에 대한 기본 이해
  • 소프트웨어 개발 수명 주기(SDLC)에 대한 친숙함
  • 소스 코드 및 소프트웨어 의존성에 대한 기본 이해
  • 보안 개념에 대한 기본 지식은 유리하지만 필수 사항은 아님

대상 고객

  • 소프트웨어 개발자
  • 소프트웨어 엔지니어
  • QA 및 소프트웨어 테스트 엔지니어
  • DevOps 및 DevSecOps 엔지니어
  • 응용 프로그램 보안 전문가
  • 보안 엔지니어
  • 소프트웨어 아키텍트
  • 기술 리드
  • 안전한 소프트웨어 개발 및 응용 프로그램 보안 테스트에 관여하는 전문가

참가자 수


참가자별 가격

회원 평가 (3)

예정된 코스

관련 카테고리