애플리케이션 보안(AppSec)은 소프트웨어 개발 라이프사이클(SDLC) 전반에 걸쳐 보안을 포함하고 자동화하여 정의됩니다. 여기에는 소스 코드 관리 도구(SCM) 및 CI/CD 파이프라인 외에도 코드가 처음 작성되는 IDE 및 CLI와 같은 개발 환경이 포함될 수 있습니다. 

때때로 개발 팀은 AppSec 팀을 게이트키퍼로 생각하고 빌드 차단을 위한 개발 목표를 방해한다고 생각하지만 이것이 전체 그림은 아닙니다. 결국, AppSec에는 프로덕션에 도달하는 취약점을 제어하는 것보다 훨씬 더 많은 것이 있습니다. 대신, AppSec 팀은 개발자가 안전하지 않은 코드 커밋이 비즈니스에 미치는 영향을 진정으로 이해하고 보안 검사를 개발 및 코드 검토 프로세스의 자연스러운 부분으로 도입할 수 있는 기회를 갖게 됩니다. 

Get the Application Security Best Practices [Cheat Sheet]

This 6-page guide goes beyond basics — it’s a deep dive into advanced, practical AppSec strategies for developers, security engineers, and DevOps teams.

TL입니다. DR: CI/CD를 통해 패키지를 코딩, 빌드 및 원격 리포지토리로 푸시하기 전에 계획 단계에 있든, 클라우드에서 임시 컨테이너를 가동하기 전에 각 커밋, 빌드 또는 배포의 일부로 보안을 강조하는 것이 중요합니다. 

이 문서에서는 개발 및 DevOps 워크플로의 모든 부분에 보안을 적용하기 위한 지침과 모범 사례를 간략하게 설명하며, 채택하기 쉬운 실용적인 기술에 중점을 둡니다.

코드, 오픈 소스 종속성, 컨테이너 이미지 또는 코드형 인프라에서 취약성, 잘못된 구성 또는 노출된 비밀을 검사하는 것부터 SCM, CI/CD 파이프라인 및 클라우드 환경에서 안전한 인증 및 권한 부여 정책을 보장하는 것까지, 릴리스 주기를 방해하지 않고 공격자보다 한 발 앞서 나가는 데 필요한 사항을 다룹니다. AppSec 모범 사례

1. Shift Left: SDLC 초기에 보안 통합

전통적으로 애플리케이션 보안은 프로덕션에 배포하기 전에 마지막 장애물로 간주되었습니다. 이러한 접근 방식은 수명 주기에서 너무 늦게 취약성이 발견되었을 때 마지막 순간에 화재 진압으로 이어졌으며, 종종 배송 및 릴리스 주기에 부정적인 영향을 미쳤습니다. 

시프트 레프트 철학 대신, 문제를 식별하고 해결하는 데 가장 적은 시간이 가장 많이 드는 SDLC에서 가능한 한 빨리 보안 관행을 개발자의 IDE, CLI 및 풀 리퀘스트 워크플로로 이동해야 한다고 주장합니다. 무엇보다도, 시프트 레프트는 코드를 작성하고 풀 리퀘스트를 검토하는 동안에(심지어 계획 단계에서도) 보안을 강조하여 첫날부터 프로세스의 일부가 되도록 합니다.

Checkmarx, Cycode 또는 Jit와 같은 정적 애플리케이션 보안 테스트(SAST) 도구를 통합하거나 소프트웨어 구성 분석(SCA) 도구 풀 리퀘스트 또는 CI 워크플로우에 Wiz Code를 사용하는 것처럼, 개발 단계에서 하드코딩된 자격 증명이나 안전하지 않은 유효성 검사와 같은 취약점을 포착할 수 있으며, 이는 코드가 프로덕션 서버에 도달하는 시점보다 훨씬 더 일찍 이루어질 수 있습니다. 

SCA는 애플리케이션을 스캔합니다.' 알려진 취약성에 대한 종속성. SCA 도구를 자동화하여 취약한 종속성을 모니터링하고 플래그를 지정하면 공급망의 보안에 대한 가시성을 확보할 수 있습니다. 위즈 코드예를 들어, 는 모든 종속성에 대한 보안 그래프를 제공하며, 이를 스캔하여 취약성에 대한 자세한 정보를 제공합니다. 

Figure 1: Security findings across code repositories

그림 1은 여러 저장소의 Wiz Code 스캔과 각각의 취약성 스캔 결과를 보여줍니다. 예를 들어 첫 번째 리포지토리에는 827개의 중요 취약성, 57개의 높음 및 12개의 중간 취약성이 있습니다. 이 정보를 손에 넣으면 엔지니어가 잠재적인 수정 사항을 찾기 시작하고 더 쉽고 저렴하게 문제를 해결할 수 있을 때 더 일찍 문제에 대응할 수 있습니다.

2. 안전한 코딩 방법 채택

안전한 코딩 방법을 사용하려면 코딩하는 동안 공격자처럼 생각해야 합니다: 위협 환경이 점점 더 정교해짐에 따라 작업하면서 명백한 실수를 찾는 것만으로는 충분하지 않습니다. 그렇기 때문에 보안 코딩 관행에는 애플리케이션이 오늘날 가장 일반적인 공격 벡터에 대해 복원력을 갖도록 하는 것이 포함됩니다 크로스 사이트 스크립팅 및 SQL 삽입.

한 가지 핵심 관행은 다음과 같습니다. 입력 유효성 검사. 효과적인 입력 유효성 검사는 기본적으로 신뢰하지 않는 것을 의미합니다 어떤 외부 입력을 선택하고 출처에 관계없이 각각의 유효성을 검사합니다. 입력 유효성 검사 프로세스를 사용하면 입력이 응용 프로그램 또는 데이터베이스와 상호 작용하기 전에 유효성이 검사되거나 삭제되거나 이스케이프되므로 안심할 수 있습니다. 

마찬가지로 출력 인코딩 는 교차 사이트 스크립팅을 방지하기 위한 웹 개발 기술입니다. 잠재적으로 유해한 사용자 입력 및 특수 문자(예: <, >, &등) 웹 페이지에 렌더링하기 전에 안전한 형식으로 변환합니다. 

예를 들어 사용자가 <script>alert('증권 시세 표시기')</script>출력 인코딩이 없으면 이 입력이 브라우저에서 일반 JavaScript로 실행되어 경고를 표시하거나 공격자가 악성 스크립트를 실행할 수 있습니다. 출력 인코딩을 사용하면 입력이 다음과 같이 렌더링됩니다. `&lt;각본&gt;alert('증권 시세 표시기')&lt;/각본&gt;`따라서 브라우저는 코드가 아닌 텍스트로 표시합니다.

또 다른 중요한 팁은? 코드에서 하드 코딩된 비밀, API 키 및 암호를 사용하지 마세요. 대신 환경 변수 또는 비밀 관리 서비스 AWS Secrets Manager 및 HashiCorp Vault와 같이 민감한 정보를 안전하게 관리하고 사용할 수 있습니다.

안전한 코드를 작성하는 습관을 들이면 처음에는 속도가 약간 느려질 수 있지만 장기적으로는 큰 도움이 됩니다. 당혹스러운 보안 침해를 피하고, 기술 부채를 줄이고, 보다 원활한 배포를 보장하는 동시에 새로운 위협에 대한 코드베이스의 복원력을 유지할 수 있습니다. Wiz Code와 같은 도구는 추가로 노출된 비밀을 감지하고 실행 중인 클라우드 환경에서 비밀이 발견된 경우 개발자 소유권 컨텍스트를 포함한 수정 워크플로를 제안하는 데 도움이 될 수 있습니다.

3. 강력한 인증 및 권한 부여 전략 구현Implement a strong authentication and authorization strategy

검증된 제품 인증 그리고 권한 부여 전략은 누가, 무엇이 응용 프로그램 및 인프라와 상호 작용할 수 있는지 제어하는 데 중요합니다. 애플리케이션, 외부 서비스 및 사용자가 애플리케이션의 서로 다른 영역에 액세스하는 최신 아키텍처에서 제대로 구현되지 않은 권한 부여 전략은 권한 상승, 무단 액세스 및 데이터 위반으로 이어질 수 있습니다. 이러한 문제를 방지하려면 최소 권한의 원칙 (PoLP) 및 역할 기반 액세스 제어Role-based access control (RBAC)를 사용하여 액터가 시스템과 상호 작용하는 방식을 제어할 수 있습니다.

최소 권한의 원칙은 사용자, 서비스 또는 응용 프로그램에 최소한의 권한을 부여하는 것을 의미합니다. 작업을 수행하는 데 필요한 권한만 가져야 하며 그 이상은 가질 수 없습니다. 광범위한 권한 집합으로 시작하는 대신 필요한 최소 권한으로 시작하여 추가 권한을 반복적으로 추가합니다. 예를 들어 데이터베이스에서 데이터를 읽는 마이크로 서비스는 반드시 필요한 경우가 아니면 쓰기 권한이 없어야 합니다.

RBAC(역할 기반 액세스 제어)는 서비스 또는 애플리케이션 각각에 대한 권한을 관리하는 대신 사전 정의된 역할을 할당하여 PoLP를 다음 단계로 끌어올립니다. 대부분의 클라우드 환경에서 RBAC는 각 역할에 대한 개별 액세스 정책을 사용하고 할당하여 달성되므로 환경 전반에서 여러 서비스 및 애플리케이션에 대한 권한을 더 쉽게 관리할 수 있습니다.

4. DAST로 런타임 취약점 재확인

배포 전 보안의 추가 계층을 위해 다음을 사용할 수도 있습니다. 동적 애플리케이션 보안 테스트 (DAST) 통합 테스트 또는 스테이징 중. DAST 도구는 실행 중인 애플리케이션에 대한 실제 공격을 시뮬레이션하여 오류 처리, 구성 오류 또는 SAST가 감지할 수 없는 열린 엔드포인트와 같은 취약성을 찾습니다. 

5. 데이터 보호 및 암호화 강조

모든 애플리케이션은 데이터를 생성하며, 빅 데이터가 증가함에 따라 데이터 볼륨을 관리할 수 없게 느껴질 수 있습니다. 사용자의 자격 증명, 재무 제표, 의료 또는 개인 데이터에는 모두 고유한 수하물이 함께 제공됩니다. 그리고 민감한 정보를 보호하지 못하면 가장 확고한 비즈니스조차도 황폐화될 수 있다는 것을 우리 모두 알고 있습니다(데이터 침해, 규정 준수 문제 및 고객 신뢰 상실 등).

가장 중요한 데이터를 보호하려면 미사용 데이터를 암호화하는 것부터 시작하세요. 즉, 사용자의 중요한 정보를 데이터베이스, 파일 시스템 또는 개체 스토리지에 저장할 때 암호화가 활성화되어 있는지 확인합니다. 대부분의 최신 클라우드 제공업체는 클릭 한 번으로 데이터를 암호화할 수 있는 기능을 제공합니다.

다음으로, 서비스, 클라이언트 및 데이터베이스 간에 데이터가 이동할 때마다 TLS(전송 계층 보안)를 사용하여 전송 중인 데이터도 암호화되도록 합니다. 이는 웹 트래픽, API 호출 및 마이크로서비스 통신에 특히 중요합니다. TLS는 누군가 네트워크 트래픽을 가로채더라도 데이터가 암호화되어 읽을 수 없도록 합니다.

6. 컨테이너 이미지, IaC 및 서버리스 구성 요소 보호

컨테이너와 서버리스 애플리케이션은 장점이자 도전 과제입니다. 민첩성, 유연성 및 확장성을 제공하지만 공격 표면도 증가하므로 세심한 주의가 필요합니다. 

안전한 이미지와 컨테이너를 구축하는 것은 프로덕션에서 애플리케이션의 무결성과 보안을 유지하는 데 필수적입니다. 먼저 취약성이 없는 기본 이미지에서 이미지를 빌드합니다. Alpine 또는 distroless 이미지와 같은 신뢰할 수 있는 최소 기본 이미지를 사용하면 공격 표면이 크게 최소화됩니다.

클라우드 컴퓨팅의 채택으로 서버리스 아키텍처는 인프라 관리의 많은 부분을 추상화했습니다. 그러나 개발자는 보안 서버리스 애플리케이션을 실행할 책임이 있습니다. AppSec 팀은 빌드 파이프라인에 통합된 표준화된 도구를 사용하여 코드 취약성, 잘못된 구성 관리, 부적절한 액세스 제어와 같은 고유한 문제를 해결해야 합니다. 예를 들어, Wiz Code와 같은 도구를 사용하면 IaC 코드에서 잘못된 구성을 검색하고 클라우드에서 서버리스 구성 요소를 보호하는 데 도움이 되는 여러 규칙의 유효성을 검사할 수 있습니다.

7. 지속적인 모니터링 및 인시던트 대응 강화

보안은 애플리케이션을 프로덕션에 배포한 후에도 중단되지 않습니다. 사실, 거기서부터 완전히 새로운 도전이 시작됩니다. 실시간 시스템을 지속적으로 모니터링하면 애플리케이션과 인프라가 실행될 때 안전한지 확인하고 잠재적인 위협을 실시간으로 탐지하는 데도 도움이 됩니다. 

로그를 집계하고 애플리케이션에서 비정상적인 패턴이나 의심스러운 활동을 식별하는 데 도움이 되는 SIEM(보안 정보 및 이벤트 관리) 도구에 투자합니다. AWS CloudTrail 또는 Azure Monitor와 같은 인기 있는 클라우드 네이티브 서비스는 API 호출, 사용자 작업 및 리소스 변경 사항을 추적할 수 있으며, New Relic 또는 Datadog와 같은 솔루션은 하이브리드 환경 전반에 걸쳐 보다 포괄적인 모니터링을 제공합니다.

Figure 2: Wiz cloud detection and response (CDR)

SIEM 정보를 다음과 결합하면 인시던트 대응 전략이를 통해 프로덕션의 위협을 신속하고 효과적으로 해결할 수 있습니다. 위즈 CDR 는 클라우드 워크로드에서 의심스러운 활동을 지속적으로 모니터링하고 클라우드 공급자로부터 인텔리전스를 수집하여 전개되는 위협을 사전에 탐지하고 대응하는 훌륭한 솔루션입니다.

8. 정기적인 보안 감사 및 침투 테스트 수행

애플리케이션이 아무리 안전하더라도 새로운 취약점이 침투할 가능성은 항상 있습니다. 정기적인 보안 감사 및 침투 테스트는 보안 조치가 시간이 지나도 효과적인지 확인하기 위한 필수 관행입니다.

보안 감사에는 시스템, 코드베이스 및 인프라에 대한 포괄적인 분석을 수행하여 모든 것이 보안 모범 사례 및 정책을 준수하는지 확인하는 것이 포함됩니다. 감사는 일반적으로 잘못된 구성, 오래된 라이브러리, 과도하게 허용적인 액세스 제어 및 시간이 지남에 따라 도입되었을 수 있는 취약성을 식별하는 데 중점을 둡니다.

침투 테스트는 애플리케이션, 네트워크 또는 인프라에 대한 실제 공격을 시뮬레이션하여 공격자가 악용할 수 있는 취약점을 조사하는 것입니다. 침투 테스터는 알려진 문제를 검사하는 것뿐만 아니라 공격자처럼 생각하고 시스템을 침해하거나 권한을 높이거나 데이터를 유출할 수 있는 창의적인 방법을 찾습니다. 정기적인 침투 테스트는 로직 결함 또는 비즈니스 로직 취약성과 같이 자동화된 스캐너가 놓칠 수 있는 취약성을 발견하는 데 도움이 됩니다.

테이크 아웃

애플리케이션 보안(AppSec) SDLC의 끝에 추가할 수 있는 것이 아닙니다. 코드 커밋에서 프로덕션 배포에 이르기까지 모든 단계에서 베이크해야 합니다. 보안 왼쪽으로 이동, 보안 코딩 표준 적용, 권한 부여 모범 사례 채택과 같이 위에서 설명한 단계를 적용하면 애플리케이션의 보안 태세를 획기적으로 개선하고 데이터 침해 및 취약성의 위험을 줄일 수 있습니다. 가장 중요한 것은 AppSec을 통해 탄력적이고 신뢰할 수 있는 시스템을 구축할 수 있다는 것입니다.

AppSec 작업을 간소화하고 자동화하려는 경우, 위즈 코드 도움이 될 수 있습니다. Wiz Code는 개발 워크플로우에 통합되도록 구축된 포괄적인 보안 플랫폼으로, 코드, OS 종속성 및 비밀에서 컨테이너, 코드형 인프라, VCS 및 CI/CD 파이프라인의 보안 태세에 이르기까지 모든 계층에서 보안 위험에 대한 실시간 가시성을 제공합니다.

Wiz Code가 애플리케이션 보안을 어떻게 강화할 수 있는지 확인할 준비가 되셨나요? 노력하다

Wiz Code의 긴밀한 통합 CI/CD 파이프라인을 사용하면 프로덕션에 도달하기 전에 중요한 문제를 감지하고 우선 순위를 지정할 수 있으며, 자동화된 스캔, 런타임 인사이트 및 상황별 우선 순위 지정을 통해 팀이 AppSec 경고 노이즈를 줄이고 가장 영향력 있는 위험에 집중할 수 있습니다. Wiz Code는 AppSec 작업을 중앙 집중화하고 통합함으로써 개발자가 안전한 애플리케이션과 인프라를 대규모로 구축하고 모든 스프린트에서 속도를 유지할 수 있도록 지원합니다.

Wiz Code가 애플리케이션 보안을 어떻게 강화할 수 있는지 확인할 준비가 되셨나요? 노력하다 애플리케이션 보안 태세를 개선하기 위한 Wiz Code 오늘.

Secure your cloud from code to production

Learn why CISOs at the fastest growing companies trust Wiz to accelerate secure cloud development.

Wiz가 귀하의 개인 데이터를 처리하는 방법에 대한 자세한 내용은 다음을 참조하십시오. 개인정보처리방침.