4.2 애플리케이션 보안

개요와 동기

애플리케이션 보안은 추상적 위협이 구체적 코드를 만나는 곳입니다. 헤드라인에 오르는 대부분의 침해는 애플리케이션 계층의 결함으로 거슬러 올라갑니다. 인젝션, 깨진 인증 흐름, 노출된 비밀, 침해된 의존성입니다. 많은 서비스를 출하하는 큰 팀에게 어려운 부분은 이런 결함이 존재함을 아는 것이 아닙니다. 여러 해에 걸쳐 수천 명의 손으로 쓰인 뻗어 나간 코드베이스 전반에서 일관되게 막는 것입니다.

기업에게 애플리케이션 보안은 고객 신뢰와 규제 의무의 문제입니다. 로그인 흐름이나 결제 경로의 결함은 사기, 벌금, 의무적 침해 공개를 촉발할 수 있습니다. 정부 시스템은 급여 자격, 세금 기록, 형사 사법 데이터, 국가 기반 시설처럼 더 이해관계가 높은 데이터와 함께 같은 기술적 위험에 직면합니다. 두 환경 모두에서 애플리케이션은 정문이며, 공격자는 끊임없이 자동으로 그것을 탐색합니다.

이 장은 애플리케이션을 탄력 있게 유지하는 실천을 다룹니다. 흔한 취약점 부류를 알고 방어하기, 입력 검증과 출력 인코딩, 인증과 인가 바로잡기, 비밀 관리, 실제 공격 표면을 점점 더 결정하는 소프트웨어 공급망 보호입니다.

함께 보기: 4.1장(보안 기초, 위협 모델링, 보안 개발 수명 주기), 10.3장(오픈 소스 공급망과 라이선스), 10.2장(SBOM, 위험, 보증).

핵심 원칙

입력을 절대 신뢰하지 마십시오. 신뢰 경계를 넘는 모든 데이터를 검증될 때까지 적대적인 것으로 다루십시오.
안전한 기본값. 안전한 길이 쉬운 길이어야 합니다. 안전하지 않은 동작은 의도적이고 눈에 보이는 노력을 요구해야 합니다.
닫힌 채로 실패하십시오. 보안 검사를 끝낼 수 없을 때는 허용하지 말고 접근을 거부하십시오.
앱 계층의 심층 방어. 검증, 인코딩, 매개변수화, 프레임워크 보호를 결합하십시오. 하나에 의존하지 마십시오.
신원과 토큰의 최소 권한. 자격 증명의 범위를 좁게 정하고 빨리 만료시키십시오.
의존성은 여러분의 코드입니다. 서드파티와 오픈 소스 구성 요소를 포함해 출하하는 모든 것의 보안에 책임이 있습니다.
즉흥보다 표준. 자체 보안 통제를 발명하는 대신 OWASP(Open Worldwide Application Security Project) ASVS 같은 검증된 프레임워크를 쓰십시오.

권장 사항

OWASP Top 10을 알고 방어하며, ASVS로 검증한다

OWASP Top 10은 가장 치명적인 웹 애플리케이션 위험의 업계 기준선 목록입니다. 깨진 접근 통제, 암호화 실패, 인젝션, 안전하지 않은 설계, 보안 설정 오류, 취약한 구성 요소, 인증 실패, 데이터 무결성 실패, 로깅 실패, 서버 측 요청 위조입니다. 서랍에 넣어 둘 컴플라이언스 참고 자료가 아니라 모든 엔지니어의 필수 지식으로 다루십시오.

엄밀하고 테스트 가능한 표준으로 OWASP 애플리케이션 보안 검증 표준(ASVS)을 채택하십시오. ASVS는 세 수준의 보증에서 보안 요구 사항을 정의해, 설계하고 테스트할 구체적이고 감사 가능한 통제를 줍니다. 각 애플리케이션의 위험에 맞는 수준을 골라 그에 대해 검증하십시오.

입력을 검증하고 출력을 인코딩한다

인젝션 결함은 도입하기가 너무 쉽기 때문에 가장 해로운 것으로 남습니다. 겹겹의 통제로 방어하십시오.

입력을 검증하되 엄격한 허용 목록(기대하는 타입, 길이, 형식, 범위)에 대해 하십시오. 가능하면 정화하지 말고 거부하십시오.
모든 데이터베이스 접근에 매개변수화된 질의와 준비된 문장을 쓰십시오. 문자열 연결로 SQL을 만들지 마십시오. 안전한 쿼리 빌더와 ORM(객체-관계 매퍼)을 올바르게 쓰십시오.
출력을 맥락에 맞게 인코딩하십시오. HTML, HTML 속성, JavaScript, URL, CSS는 각각 다른 인코딩이 필요합니다. 프레임워크의 자동 이스케이프에 의지하고 그 한계를 이해하십시오.
출력 인코딩과 두 번째 계층으로서의 강한 콘텐츠 보안 정책으로 교차 사이트 스크립팅(XSS)을 막으십시오.
신뢰할 수 없는 데이터로 셸을 부르지 않고, 로직이 없거나 샌드박스된 템플릿을 써서 명령 및 템플릿 인젝션을 막으십시오.

인증과 인가를 바로잡는다

인증은 사용자가 누구인지 증명합니다. 인가는 그들이 무엇을 할 수 있는지 결정합니다. 둘 다 자주 실패하므로 바로잡으십시오.

확립된 프로토콜을 선호하십시오. 위임된 인가에는 OAuth 2.0, 인증에는 OpenID Connect(OIDC). 이것들을 처음부터 만들지 마십시오.
특히 권한이 있는 관리자 접근에 다중 요소 인증(MFA)을 시행하십시오.
비밀번호는 현대적이고, 느리고, 메모리 하드한 알고리즘(Argon2나 bcrypt 같은)을 쓴 솔트 해시로만 저장하십시오. 평문 자격 증명을 저장하거나 기록하지 마십시오.
세션을 신중히 관리하십시오. 암호학적으로 강한 토큰을 생성하고, secure 및 HttpOnly 쿠키 플래그를 설정하고, 권한 변경 시 교체하고, 유휴 세션을 만료시키십시오.
모든 요청에 서버에서 인가를 시행하여, 인증된 주체가 특정 자원을 소유하거나 접근할 수 있는지 확인하십시오. 깨진 객체 수준 인가(ID를 바꿔 다른 사용자의 레코드에 접근)는 가장 흔하고 심각한 API 결함 중 하나입니다.
정책이 일관되고 감사 가능하도록 실용적인 곳에서는 인가 로직을 중앙화하십시오.

비밀을 관리하고 키를 교체한다

소스 코드에 하드코딩된 비밀은 침해의 영원한 원인입니다. 비밀 관리에 규율 있는 습관을 만드십시오.

비밀을 전용 비밀 관리자나 볼트에 저장하십시오. 소스, 설정 파일, 버전 관리에 체크인된 환경 변수에는 절대 두지 마십시오.
커밋과 저장소에서 유출된 비밀을 자동으로 스캔하고, 그것을 도입하는 병합을 막으십시오.
키와 자격 증명을 정기적으로, 그리고 노출이 의심되면 즉시 교체하십시오. 수명이 긴 정적인 것보다 수명이 짧고 자동 발급되는 자격 증명을 선호하십시오.
모든 비밀에 최소 권한을 적용하십시오. 정확히 필요한 것으로 범위를 정하십시오.
비밀을 저장 시와 전송 중에 암호화하고, 접근을 감사하십시오.

소프트웨어 공급망을 보호한다

현대적 애플리케이션은 대부분 서드파티 구성 요소로 조립되므로, 공급망이 주된 공격 표면입니다.

출하하는 것을 정확히 알고 새 취약점이 닿을 때 빠르게 대응할 수 있도록 모든 애플리케이션의 소프트웨어 자재 명세서(SBOM)를 유지하십시오.
의존성을 지속적으로 스캔하고(소프트웨어 구성 분석, SCA) 알려진 취약한 구성 요소를 즉시 시정하십시오.
의존성 버전을 고정하고 검증하십시오. 락 파일과 신뢰할 수 있는 레지스트리를 쓰십시오.
빌드 무결성을 높이려고 SLSA(Supply-chain Levels for Software Artifacts)를 채택하고, 산출물이 어떻게 빌드되었는지 기술하는 출처 증명을 생성하십시오.
실행되는 것이 빌드한 것임을 신뢰할 수 있도록 산출물에 서명하고 배포 전에 서명을 검증하십시오.
빌드 시스템 자체를 보호하십시오. 침해된 CI 파이프라인은 모든 다운스트림 소비자에게 악성 코드를 주입할 수 있습니다.

장단점

결정	장점	단점
신원 제공자(OIDC) 구매/채택	검증됨. MFA 내장. 보호할 코드가 적음	벤더 의존. 통합 노력. 비용
맞춤 인증 구축	완전한 통제. 외부 의존성 없음	틀리기 극히 쉬움. 높은 유지보수
엄격한 허용 목록 검증	취약점 부류 전체를 차단	정당한 엣지 케이스를 깨뜨릴 수 있음. 선행 작업 증가
수명이 짧은 자격 증명	작은 침해 구간. 자동 폐기	견고한 발급 인프라 필요
적극적 의존성 갱신	알려진 취약점이 적음	변동. 호환 파괴 가능성. 테스트 부담
SBOM + 서명 + 출처	빠른 인시던트 대응. 검증 가능한 신뢰	도구와 프로세스 투자. 문화 변화

되풀이되는 트레이드오프는 선행 엄밀함 대 지속적 노출입니다. 맞춤 인증을 만들거나 의존성 위생을 건너뛰는 것은 오늘은 더 빠르게 느껴지고 나중에 막대한 비용이 듭니다. 검증된 표준과 자동화된 공급망 통제를 채택하는 것은 지금 노력이 들지만, 한정되지 않고 예측할 수 없는 위험을 관리되고 한정된 위험으로 바꿉니다. 큰 팀에서는 자동화의 배수 효과가 가장 중요합니다. 포장된 길 템플릿에 한 번 적용한 통제가 그것을 쓰는 모든 서비스를 보호합니다.

팀과 논의할 질문

어떤 ASVS 통제를 포장된 길 프레임워크에 구워 넣어 엔지니어가 공짜로 얻게 하겠습니까? 큰 팀에서 지렛대 효과가 가장 큰 수는 안전한 길을 기본으로 만드는 것이며, 공유 프레임워크에 한 번 쓴 통제가 그것을 채택하는 모든 서비스를 보호합니다. 어떤 ASVS 요구 사항(매개변수화된 질의, 출력 인코딩, 안전한 세션 플래그, 서버 측 인가 검사)이 각 엔지니어의 기억이 아니라 템플릿에 속하는지 결정하십시오. 기업과 정부 포트폴리오에서는 어느 애플리케이션이 ASVS 2수준이고 어느 것이 3수준을 필요로 하는지도 결정하고, 각각이 닿는 데이터의 민감도에 연결하십시오. 서비스 목록을 가져와 어느 것이 이미 이런 기본값을 상속하고 어느 것이 보안을 손으로 다시 구현하는지 표시하십시오. 손으로 만든 것이 인젝션과 깨진 접근 통제가 숨은 곳이기 때문입니다. 안전한 기본값이 위키 페이지에만 있으면 전달 압박 아래서 건너뛰어질 것이므로 코드에 넣으십시오.
새 API만이 아니라 모든 API에 걸쳐 깨진 객체 수준 인가를 어떻게 찾아 고치겠습니까? ID를 바꿔 다른 사용자의 레코드에 접근하는 것은 가장 흔하고 심각한 API 결함 중 하나이며, 현재 표준보다 앞선 오래된 엔드포인트에 숨어 있습니다. 모든 요청과 모든 객체에 서버 측 인가를 하는 것이 규칙이지만, 어려운 부분은 많은 손으로 쓰인 뻗어 나간 여러 해 된 코드베이스 전반에서 그것이 유지됨을 검증하는 것입니다. 인가 로직을 중앙화할지, 테넌트 간 접근을 시도하는 자동화된 테스트를 추가할지, 위험이 가장 높은 API부터 표적 테스트를 실행할지 결정하십시오. 객체 식별자를 노출하는 엔드포인트의 목록을 가져와 돌려주는 것의 민감도로 순위를 매기십시오. 의도적인 일제 점검이 없으면 이 결함을 계속 출하하다가 연구자나 공격자가 발견해야만 알게 될 것입니다.
다음 광범위한 의존성 취약점에 대한 계획은 무엇이며, 영향받는 모든 서비스를 얼마나 빨리 찾아 패치할 수 있습니까? 인기 있는 라이브러리에 치명적 결함이 닿을 때, 정확한 SBOM이 있는 회사는 몇 시간 안에 영향받는 서비스를 식별하는 반면 다른 곳은 몇 주를 찾아다니며, 그 속도 간극이 입을 피해를 결정합니다. 모든 산출물에 소프트웨어 자재 명세서를 만드는지, 모든 파이프라인에서 의존성 스캔이 돌아가는지, 긴급 패치 결정을 누가 소유하는지 지금 결정하십시오. 규제되고 정부인 구매자에게 SBOM과 서명된 출처는 점점 사업을 하는 조건이므로, 이 준비 상태는 매출도 보호합니다. 훈련에 대한 정직한 답을 가져오십시오. 널리 쓰는 라이브러리를 하나 골라 그것을 출하하는 모든 서비스를 나열하는 데 얼마나 걸리는지 재 보십시오. 답이 며칠 단위라면 다음 인시던트가 강제하기 전에 목록과 서명에 투자하십시오.
수명이 긴 정적 비밀에서 수명이 짧고 자동 발급되는 자격 증명으로 어떻게 옮기며, 오늘 무엇이 그것을 막고 있습니까? 하드코딩되고 수명이 긴 비밀은 침해의 영원한 원인이고, 해법인 필요할 때 발급되는 수명이 짧은 자격 증명은 오래된 시스템이 흔히 쓸 수 없는 발급 인프라에 달려 있습니다. 큰 팀에서 위험은 고르지 않은 채택입니다. 현대적 플랫폼은 키를 매시간 교체하는데 레거시 서비스는 여전히 설정 파일에 정적 데이터베이스 비밀번호를 담아 출하합니다. 어떤 워크로드가 지금 비밀 관리자나 워크로드 신원 시스템을 쓸 수 있는지, 어떤 것이 먼저 투자가 필요한지, 키가 유출된 것으로 의심되는 순간 교체 런북을 누가 소유하는지 결정하십시오. 사용 중인 모든 자격 증명의 목록, 수명, 노출 시 영향 범위, 병합 전에 커밋 스캔이 잡을지를 가져오십시오. 기업과 정부 환경에서는 이를 감사에 연결하십시오. 검사관은 모든 비밀에 대한 교체, 범위가 정해진 접근, 접근 기록의 증거를 점점 더 기대하며, 다운타임 없이 교체할 수 없는 정적 자격 증명은 쓰이기를 기다리는 지적 사항입니다.
어디서 여전히 자체 개발하거나 일관성 없는 인증을 운영하며, 검증된 프로토콜로 통합할 계획은 무엇입니까? 인증을 만드는 것은 미묘하고 악용 가능한 결함을 도입하는 가장 쉬운 방법 중 하나이지만, 대부분의 큰 자산은 OAuth 2.0과 OIDC로 표준화하기로 한 결정보다 앞선 레거시 로그인 흐름을 적어도 하나는 지닙니다. 경쟁하는 압력은 실제입니다. 옛 흐름을 이전하면 기존 사용자와 통합을 깨뜨릴 위험이 있고, 그대로 두면 가치가 높은 표적을 방어가 부실한 채로 둡니다. 단일 신원 제공자로 통합하고, MFA를 균일하게 시행하고, 맞춤 흐름 각각을 퇴역시킬 기한을 정할지, 보완 통제와 함께 문서화된 예외를 받아들일지 결정하십시오. 장치군의 모든 인증 경로, 어느 것이 MFA를 시행하는지, 어느 것이 현대적 메모리 하드 해시로 비밀번호를 저장하는지, 어느 것이 맞춤인지의 지도를 가져오십시오. 기업과 정부 포트폴리오에서는 컴플라이언스 각도를 더하십시오. NIST SP 800-63 같은 표준은 신원 보증에 대한 구체적 기대를 정하며, 이를 입증할 수 없는 자체 개발 흐름은 감사나 운영 인가 검토를 견디지 못합니다.
이런 통제가 프로덕션에서 실제로 유지됨을 어떻게 검증하며, 단언이 아니라 증거로 입증할 수 있습니까? 안전한 기본값을 쓰는 것과 모든 서비스가 여전히 그것을 지킴을 아는 것은 다르며, 코드가 바뀌고, 예외가 쌓이고, 새 엔드포인트가 출하되면서 통제는 조용히 썩습니다. 큰 팀에서 질문은 커버리지입니다. 어느 서비스가 정적 분석, 의존성 스캔, 동적 또는 침투 테스트를 돌리며, 그것을 건너뛰는 서비스가 위험이 가장 높은 애플리케이션이 아님을 어떻게 압니까? 파이프라인에서 필수인 검증과 주기적인 검증이 무엇인지, 누가 발견 사항을 분류하는지, 통제가 특정 날짜에 테스트되고 통과했음을 보일 어떤 증거를 보관하는지 결정하십시오. 현재 커버리지 지도, 심각도별 평균 시정 시간, 최근 테스트가 없는 애플리케이션의 목록을 가져오십시오. 규제되고 정부인 맥락에서 이 증거는 선택이 아닙니다. 감사자, 인가 담당관, 침해 조사관 모두 통제가 검증되었다는 증명을 요구하며, 테스트 기록 없는 정책은 거의 그들을 만족시키지 못합니다.

분야별 관점

스타트업. 엔지니어 두세 명과 보안 전문가가 없다면 지렛대는 보안을 만드는 것이 아니라 상속하는 것입니다. 관리형 OIDC 신원 제공자를 채택하고, ORM이 기본으로 질의를 매개변수화하는 프레임워크에 기대고, 비밀을 팀원이 실수로 커밋할 수 있는 .env 파일이 아닌 플랫폼의 비밀 관리자에 두십시오. 패치 풀 리퀘스트를 여는 자동 의존성 스캔을 켜고 지금은 그것으로 충분하다고 여기십시오. 맞춤 인증이나 암호를 만들지 마십시오. 주입된 질의 하나나 유출된 키 하나가 고객이 생기기도 전에 회사를 끝낼 수 있기 때문입니다.

소기업. 애플리케이션 보안 전문가도 빠듯한 예산도 없을 테니, 전담 기능에 인력을 대는 대신 이미 값을 치르는 도구와 플랫폼에 내장된 통제를 사십시오. MFA가 포함된 호스팅 신원 제공자, 매개변수화된 접근으로 이끄는 관리형 데이터베이스, 기본으로 유출된 비밀을 커밋에서 스캔하는 저장소 호스트를 고르십시오. 희소한 주의를 실제 침해 대부분을 일으키는 OWASP Top 10 기본기에 집중하고, 아무렇지 않게 끌 수 없는 안전한 기본값을 출하하는 벤더를 선호하십시오.

대기업. 많은 팀에 걸쳐 과제는 일관성입니다. ASVS 통제를 포장된 길 프레임워크에 구워 넣어 모든 새 서비스가 매개변수화된 질의, 출력 인코딩, 안전한 세션, 서버 측 인가를 공짜로 상속하게 하십시오. 다음 광범위한 라이브러리 취약점이 몇 주가 아니라 몇 시간의 문제가 되도록 정확한 SBOM과 장치군 전체의 의존성 스캔을 운영하고, 테넌트 간 접근이 테스트 가능해지도록 인가 정책을 중앙화하십시오. MFA가 시행되는 하나의 신원 제공자로 표준화하고, 위험 등급별 ASVS 수준과 감사된 증거로 애플리케이션 보안을 다스려지는 포트폴리오로 관리하십시오.

정부. 조달 규칙, 투명성, 공적 책임성이 구현만이 아니라 입증해야 하는 통제를 형성합니다. 시민 대면 서비스를 데이터 민감도에 맞는 수준의 OWASP ASVS에 대해 검증하고, 공급망 의무를 충족하도록 배포된 모든 산출물에 서명하고 SLSA에 따라 출처를 증명하며, 전체 접근 기록이 있는 중앙 볼트에서 수명이 짧은 자격 증명을 발급하십시오. 감사자와 인가 담당관에게 소스에서 프로덕션까지 문서화된 보관 사슬을 보일 것을 예상하고, 신원 보증을 NIST SP 800-63 같은 공개 표준에 맞추십시오.

사례

스타트업. 엔지니어 세 명의 SaaS 팀은 자체 로그인을 만드는 것을 건너뛰고 첫날부터 관리형 OIDC 제공자를 채택해, 틀릴 여유가 없는 보안 핵심 코드를 쓰지 않고 MFA와 안전한 비밀번호 재설정을 얻습니다. 프레임워크의 ORM에 기대 질의가 기본으로 매개변수화되고, 비밀은 팀원이 실수로 커밋할 수 있는 .env 파일이 아닌 플랫폼의 비밀 관리자에 있으며, 라이브러리가 패치가 필요할 때 풀 리퀘스트를 여는 자동 의존성 스캔을 켭니다. 이 중 어느 것도 팀을 늦추지 않으며, 유출된 키 하나나 주입된 질의 하나가 고객이 생기기도 전에 회사를 끝내지 않는다는 뜻입니다.

대기업. 수천만 쇼핑객을 섬기는 한 소매 플랫폼이 단일 신원 제공자를 통한 OIDC로 인증을 표준화하며, 직원에게 MFA를, 가치가 높은 계정 변경에 단계 상승 인증을 시행합니다. 모든 데이터베이스 접근은 질의를 매개변수화하도록 설정된 ORM을 거치고, 콘텐츠 보안 정책이 출력 인코딩을 보강합니다. 인기 있는 로깅 라이브러리의 널리 알려진 취약점 뒤에, 회사의 SBOM 덕에 몇 시간 안에 영향받는 모든 서비스를 식별하고 이틀 안에 패치하는 동안, 목록이 없던 경쟁사들은 몇 주를 찾아 헤맸습니다.

정부. 한 연방 급여 기관이 OWASP ASVS 2수준에 대해 검증된 시민 대면 서비스를 만들고, 가장 민감한 기록을 다루는 구성 요소에는 3수준을 씁니다. 비밀은 수명이 짧은 자격 증명을 발급하는 중앙 볼트에 있고, 커밋 스캔이 유출된 모든 키를 막습니다. 배포된 모든 산출물이 서명되고 출처가 SLSA에 따라 증명되어, 검증 가능한 소프트웨어 공급망에 대한 연방 의무를 충족하고 감사자에게 소스에서 프로덕션까지 분명한 보관 사슬을 줍니다.

비즈니스 사례: 동기, ROI, TCO

애플리케이션 보안 지출은 가장 가능성 높고 가장 비싼 침해 범주를 사서 줄입니다. 총소유비용에는 도구(스캐너, 비밀 관리자, 신원 제공자), 발견 사항을 시정하는 엔지니어 시간, 안전한 기본값의 약간의 마찰이 포함됩니다. 이에 맞서 건너뛰는 비용을 따져 보십시오. 인젝션과 깨진 접근 통제 침해는 일상적으로 수백만 건의 레코드를 노출시켜, 규제 벌금, 의무적 통지, 사기 손실, 시정 스프린트, 여러 해 매출을 억누르는 평판 손상을 촉발합니다.

통제가 자동화되고 재사용될 때 ROI가 가장 강합니다. 잘 설정된 단일 신원 통합, 공유 프레임워크의 하나의 강화된 질의 계층, 취약한 의존성을 막는 하나의 파이프라인이 서비스당 한계 비용으로 전체 장치군을 보호합니다. 특히 공급망 통제는 선택에서 필수가 되었습니다. 침해된 의존성 하나가 모든 고객을 피해자로 만들 수 있고, 규제 기관과 기업 구매자는 사업을 하는 조건으로 SBOM과 서명된 출처를 점점 요구합니다. 리더십을 설득할 때 투자를 구체적이고 이름 붙은 위험, 그리고 충족하지 못하면 매출을 막는 조달 및 컴플라이언스 요건에 연결하십시오.

안티패턴과 함정

자체 암호나 인증 만들기. 거의 항상 미묘하고 악용 가능한 결함을 낳습니다.
클라이언트 측 검증만. 쉽게 우회됩니다. 서버가 모든 것을 다시 검증해야 합니다.
차단 목록 정화. 좋은 문자를 허용 목록에 두는 대신 “나쁜” 문자를 제거하려는 것. 공격자가 틈을 찾습니다.
소스나 환경 파일의 비밀. 자격 증명 유출의 가장 흔한 단일 원인.
객체 접근에 대한 인가 무시. 인증된 사용자가 추측할 수 있는 ID의 어떤 객체든 접근할 수 있다고 가정하는 것.
설정하고 잊는 의존성. 침해가 강제할 때까지 서드파티 구성 요소를 갱신하지 않는 것.
Top 10을 결승선으로 취급. 그것은 포괄적 표준이 아니라 바닥입니다. 깊이를 위해서는 ASVS를 쓰십시오.
민감한 데이터 로깅. 로그의 비밀번호, 토큰, PII(개인 식별 정보)는 일어나기를 기다리는 침해가 됩니다.

성숙도 모델

1단계: 시작. 애플리케이션 보안이 개별 개발자의 지식에 의존하고 인시던트 후에만 반응합니다. 표준 통제가 없습니다. 비밀이 소스에 있습니다. 의존성은 거의 갱신되지 않습니다. 인증은 맞춤이고 즉흥적이며, 인젝션이나 깨진 접근 통제 결함은 프로세스가 아니라 운으로 발견됩니다.

2단계: 발전. 기본 실천이 나타나지만 팀마다 다릅니다. OWASP Top 10 인식이 퍼지고, 일부 프레임워크 수준 보호가 있으며, 비밀 관리자가 있지만 고르지 않게 쓰입니다. 의존성 스캔은 가끔 돕니다. 새 시스템은 표준 신원 제공자를 채택하는 반면, 오래된 서비스는 자체 개발한 로그인 흐름을 그대로 둡니다.

3단계: 표준화. 통제가 문서화되어 조직 전체에서 시행됩니다. ASVS 기반 요구 사항이 위험 등급별로 정해지고, 매개변수화된 질의와 출력 인코딩이 표준이며, MFA가 있는 중앙 신원 제공자가 요구됩니다. 비밀이 관리되고 자동으로 스캔되며, SBOM이 생성되고, 모든 파이프라인에서 의존성 스캔이 돕니다.

4단계: 관리. 실천이 기준선에 대해 측정되고 통제됩니다. 스캔과 테스트 커버리지, 심각도별 평균 시정 시간, 포장된 길 기본값을 상속하는 서비스의 비율, 자격 증명과 비밀 교체 연령, ASVS 적합성이 모두 대시보드에서 추적됩니다. 예외는 만료일과 함께 기록되고, 기준선에서의 표류는 조치를 촉발하며, 릴리스는 판단이 아니라 정의된 보안 임계값으로 관문 통제됩니다.

5단계: 오케스트레이션. 보안이 조직 전체에서 지속적으로 개선되고 통합됩니다. 안전한 기본값이 포장된 길 프레임워크에 구워져 안전한 길이 자동이고, 수명이 짧은 자격 증명이 어디서나 쓰이며, 서명과 출처(SLSA)를 갖춘 완전한 공급망 보증이 표준입니다. 검증은 지속적이고, 새 취약점에 대한 대응은 빠르고 측정되며, 각 인시던트가 공유 템플릿에 되먹임되어 하나의 수정이 장치군 전체를 강화합니다.

논의를 위한 아이디어

많은 서비스에 걸쳐 일관되고 유지보수 가능하려면 인가 로직은 어디에 살아야 합니까?
노출과 변동 사이의 트레이드오프를 감안할 때 의존성을 얼마나 적극적으로 갱신해야 합니까?
포트폴리오의 각 애플리케이션 부류에 알맞은 ASVS 수준은 무엇입니까?
깨지기 쉬운 발급 인프라를 만들지 않고 수명이 긴 비밀을 어떻게 없앱니까?
모든 산출물에 대해 SBOM과 출처를 만들고 소비하려면 조직에 무엇이 필요합니까?
전달 압박 아래서 안전한 기본값이 꺼지지 않게 하려면 어떻게 합니까?

핵심 요점

OWASP Top 10은 필수 지식이고, ASVS는 테스트 가능한 표준을 제공합니다.
입력 검증, 매개변수화, 출력 인코딩을 겹쳐 인젝션과 XSS를 무너뜨리십시오.
검증된 프로토콜(OAuth 2.0, OIDC)을 쓰고 MFA를 시행하십시오. 인증을 처음부터 만들지 마십시오.
모든 요청과 모든 객체에 서버 측 인가를 시행하십시오.
비밀을 소스 밖에 두고, 중앙에서 관리하고, 수명이 짧은 자격 증명으로 교체하십시오.
공급망은 주된 공격 표면입니다. SBOM, SCA, 서명, 출처(SLSA)를 쓰십시오.
자동화되고 재사용 가능한 통제는 서비스당 한계 비용으로 장치군 전체를 보호합니다.

참고 문헌과 더 읽을거리

OWASP, Top 10 Web Application Security Risks
OWASP, Application Security Verification Standard (ASVS)
OWASP, Cheat Sheet Series (Input Validation, Authentication, Authorisation, Secrets Management)
Dafydd Stuttard and Marcus Pinto, The Web Application Hacker’s Handbook
Aaron Parecki, OAuth 2.0 Simplified
National Institute of Standards and Technology, SP 800-63: Digital Identity Guidelines
Cloud Native Computing Foundation and OpenSSF, SLSA framework and Supply-chain Security guidance