시프트 레프트(Shift Left)와 시프트 라이트(Shift Right) 비교

소프트웨어 개발 라이프사이클 전반에서 테스트는 사용자 기대치, 기능 요구 사항 및 보안 조치를 구현하는 데 매우 중요합니다. 시프트 레프트는 가능한 한 빨리 보안 테스트를 통합하여 개발 초기에 취약점을 발견하고 결함을 수정하는 방식입니다. 시프트 라이트는 프로덕션 단계에서 사용자 행동, 사용량, 성능 및 보안 메트릭을 모니터링하여 소프트웨어 운용성을 검증하는 방식입니다.

시프트 라이트와 시프트 레프트 모두 지속적인 테스트 방법을 중심으로 DevOps 프로세스 및 소프트웨어 개발 라이프사이클(SDLC) 전반에서 새로운 제품과 기능의 품질 및 성능을 평가하고 보장합니다. 애자일 사례의 시프트 레프트와 시프트 라이트 원칙은 잠재적인 문제가 큰 문제로 이어지기 전에 이를 파악할 수 있도록 '작게 실패하고 빠르게 복구'하자는 사고에 기반합니다.

시프트 레프트와 시프트 라이트를 이해하려면 먼저 소프트웨어 개발 라이프사이클을 왼쪽에서 오른쪽으로 이어지는 선으로 생각하면 좋습니다. 이 선의 왼쪽 절반은 코딩 단계와 구축 단계로 구성되며, 오른쪽 절반은 소프트웨어의 배포 및 모니터링을 의미하는 프로덕션 단계입니다.

전통적으로 소프트웨어의 보안 테스트는 SDLC의 후반부, 즉 프로덕션으로 진행하기 직전에 실시했습니다. 그러나 테스트가 지연되면 소프트웨어가 라이프사이클 프로세스의 다음 단계로 진행되면서 보안 결함을 감지하지 못할 가능성이 있습니다. 이 경우 취약점이 발견되면 팀은 애플리케이션에 컴파일된 결함을 격리하고 수정하기 위해 복잡하고 비용이 많이 드는 재작업을 해야 합니다.

결국 조직은 SDLC 초기에 장애 요인을 제거할 수 있으면 결함과 오류 수정 비용이 줄고, 리소스가 절약되며, 더 나은 완성품을 만들 수 있다는 사실을 깨닫기 시작했습니다. 이때 '보안을 왼쪽으로 이동(즉, 시프트 레프트)'한다는 개념이 탄생했으며, 그때부터 현대적인 소프트웨어 개발의 기본이 되었습니다.

개발자는 보안 전문가를 자처하지도 않고, 그렇게 되고 싶어 하지도 않습니다. 특히 다른 개발자가 실수로 심각한 취약점을 유발하는 코드를 작성했을 때 이를 수정할 책임이 있는 개발자는 릴리스 주기를 따라잡기가 쉽지 않습니다.

소프트웨어 아키텍처의 복잡성과 규모가 더욱 커지고 분산되면서 조직 전체에서 보안을 효과적으로 모니터링하고 관리하기가 더욱 어려워지고 있습니다. 하이브리드 환경 전반에서 지속적인 배포를 수용하는 현대적인 소프트웨어 배포 방법은 새로운 보안 접근 방식, 즉 애플리케이션 개발 프로세스 초기에 보안 가드레일을 제공하고 각 단계에서 보안을 자동화하며 보안을 비즈니스 지원 요소로 전환하는 방식이 필요합니다.

개발자는 시프트 레프트 전략을 사전 예방적 조치로 사용하여 파이프라인의 후반 단계까지 결함이 남아있지 않도록 이를 식별하고 수정하여 애플리케이션 보안을 강화할 수 있습니다. 이 전략에서는 보안 사례를 통합하고, 보안을 나중에 처리할 업무로 남겨두기보다는 개발 프로세스 초기에 가능한 한 빨리 테스트합니다. 시프트 레프트는 지속적인 조기 보안 통합을 강조하는 DevSecOps의 부상과 밀접한 관련이 있습니다. 

조직은 빌드, 배포 및 런타임 단계 전반에서 보안 인시던트를 경험합니다. 시프트 레프트 방식으로 DevSecOps를 구현하고 자동화하면 빌드와 배포 단계에서 사용자 오류를 줄이고 런타임에서 워크로드를 보호할 수 있는 개발자 친화적인 가드레일을 제공합니다.

시프트 레프트 테스트와 관련된 기술에는 다음이 포함될 수 있습니다.

• 정적 애플리케이션 보안 테스트(SAST) - 애플리케이션의 소스, 바이트코드 또는 바이너리 코드에 대한 보안 취약점 분석
• 동적 애플리케이션 보안 테스트(DAST) - 실행 중인 대상에 자동화된 보안 검사를 수행하여 잠재적인 보안 결함을 파악할 때 사용되는 블랙박스 테스트 방법론
• 위협 모델링 - 특정 시스템에서 내려진 각 의사 결정을 검토하고 이러한 결정이 지금 즉시 또는 앞으로 보안 프로필에 미칠 영향을 추정하는 프로세스
• 보안 아키텍처 검토 - 현재와 미래의 위협 및 위험에 대한 조직의 보안 조치를 강화하기 위한 위험 식별, 평가, 완화
• 컨테이너 이미지 검사 - 잠재적 보안 위협을 감지하기 위한 계층별 컨테이너 이미지 계층 분석
• 코드 서명 - 프로그램, 파일 또는 소프트웨어 업데이트에 디지털 서명을 넣어 설치 및 실행 시 진위 여부와 무결성을 확인하는 방법 

시프트 레프트 방식의 목적은 코드 작성 시 취약점을 조기에 발견해 수정하는 것입니다. 보안을 강화할 뿐만 아니라, 고품질의 소프트웨어를 더 빠르게 자주 제공하여 사용자 환경과 기능을 개선할 수 있기 때문입니다. 또한 개발 주기 초기에 소프트웨어 버그를 감지하고 해결하여 개발 효율성을 높이고 오버헤드 비용을 줄일 수 있습니다. 

위협 벡터가 점점 더 정교해지고 공격 표면이 기하급수적으로 확대되면서, 기업은 빌드 단계에서 시프트 레프트 테스트에 의존하는 것만으로는 진화하는 보안 위협을 제대로 차단하기 어렵다는 것을 깨달았습니다.

이런 배경에서 시프트 레프트 테스트와 상호 보완적인 시프트 라이트 테스트가 나오게 되었습니다. 시프트 라이트란 프로덕션 이후 환경에서 테스트, 품질 보증 및 성능 평가 사례를 계속하는 것입니다. 

시프트 라이트 테스트를 구현하려는 개발 팀은 소프트웨어 개발 주기가 끝날 무렵에 기능, 성능, 내결함성 및 사용자 환경을 검사하기 위한 통제된 실험을 수행합니다.

주요 제어 및 실시간 가시성을 위한 시프트 라이트 테스트 관련 기술에는 다음이 포함될 수 있습니다.

• SIEM - 보안 정보 및 이벤트 관리(Security Information and Event Management). 조직이 위협을 감지, 분석하고 그에 대응하도록 지원하는 솔루션입니다.
• SOAR - 보안 오케스트레이션, 자동화 및 대응(Security Orchestration, Automation, and Response). 다양한 구성원과 툴 간 태스크를 조정, 실행 및 자동화하여 IT 팀의 부담을 덜어줍니다.
• 카나리아 배포 - 전체 사용자 기반에 릴리스하기 전에 일부 사용자를 대상으로 새로운 기능을 테스트합니다.
• 배포 링 - 사용자에게 미치는 영향을 제한하면서 프로덕션 환경에서 확장 프로그램의 변경 사항을 점진적으로 배포하고 검증합니다.
• A/B 테스트 - 대조군을 만들고 다양한 시나리오, 기능, 디자인 등을 도입하여 가설을 테스트하고 의도한 반응과 시나리오 전반의 반응을 비교 측정하는 접근 방식입니다.
• 결함 주입 테스트 - 시스템에 의도적으로 결함을 도입하여 테스트하는 것입니다.
• API 보안 테스트 - 이그레스 트래픽과 아웃바운드 호출을 추적하여 동작을 이해하고 보안 인시던트를 감지합니다. Istio는 기반 통신 채널을 제공하고 대규모로 서비스 통신의 인증, 권한 부여 및 암호화를 관리하는 데 도움이 되는 서비스 메쉬 플랫폼입니다.
• 카오스 엔지니어링 - 시스템의 복원력을 테스트하기 위해 '일부러 고장 내는 것'입니다.
• 블루-그린 배포 - 사용자 트래픽을 이전 버전의 애플리케이션에서 거의 동일한 새 릴리스(둘 다 프로덕션 환경에서 실행 중)로 점진적으로 이전하는 애플리케이션 릴리스 모델입니다. 

팀은 실제 환경에서 소프트웨어의 동작을 관찰함으로써 런타임 중 보안 위협을 사전에 감지하고 애플리케이션이 의도대로 작동하는지 확인할 수 있습니다. 시프트 라이트 테스트를 사용하면 사용자로부터 지속적인 실시간 피드백을 받을 수 있을 뿐 아니라 예상치 못했던 문제까지 분석할 수 있습니다. 

조직이 클라우드 네이티브 구조로 전환하고 마이크로서비스 및 컨테이너와 같은 기술을 포함하도록 애플리케이션을 현대화할 때, 모범 사례는 시프트 레프트과 시프트 라이트 전략을 모두 도입하는 것입니다. SDLC의 모든 단계에서 엔드 투 엔드 테스트를 실행할 역량을 팀에 제공하는 조직은 지속적 통합 및 지속적 제공(CI/CD)이라는 궁극적 목표에 더 다가갈 수 있습니다.

시프트 레프트 및 시프트 라이트 방법론을 도입하면 효율성 향상, 제품 품질 개선, 보안 강화, 시장 출시 시간 단축, 사용자 만족도 상승 등의 장점을 누릴 수 있습니다. 또한 조직은 감지 시간을 기준으로 버그 수정에 드는 상대적 비용이 점차 늘어난다는 사실을 발견했습니다. 즉, 문제를 해결하기 위해 오래 기다릴수록 더 많은 비용이 발생할 가능성이 높습니다. 따라서 시프트 레프트라는 예방 조치를 취하면 수익성이 크게 달라질 수 있습니다. 

소프트웨어 공급망을 보호하려면 다면적인 접근 방식이 필요합니다. 소프트웨어 공급망 보안을 개선할 수 있는 방법은 다양하며, 각 작업은 조직과 고객을 위한 또 다른 보호 계층을 추가합니다.

조직의 개발 라이프사이클에서 시프트 레프트와 시프트 라이트 원칙을 구현하려면 먼저 SBOM(Software Bill of Materials), 즉 아티팩트의 일부인 소스 코드, 오픈소스 및 소프트웨어 라이브러리, 미들웨어, 개발 프레임워크를 포함한 모든 소스와 종속성의 중첩된 인벤토리를 먼저 구현하세요.

그런 다음 자동화된 테스트를 구현하여 소프트웨어 개발 및 배포 파이프라인 전반에서 데이터와 분석 결과를 수집합니다. 각 SDLC 단계의 지속적인 테스트는 성능을 모니터링하고 근본 원인을 감지하는 가장 좋은 방법입니다.

무엇보다 중요한 것은 각 팀 내에서 문제 영역을 파악하고 적합한 툴을 찾을 수 있도록 부서 내 및 부서 간 서로 협업하고 소통하는 것입니다. 

빠르게 진화하는 오늘날 기술 환경에서 애플리케이션 배포의 확장성, 이식성, 효율성을 높이기 위해 컨테이너화를 도입하는 조직이 점점 더 많아지고 있습니다. 컨테이너화는 나름의 장점이 있지만, 컨테이너화된 애플리케이션의 안전성, 기밀성, 접근성 개선을 위해 해결해야 하는 IT 보안 문제도 발생할 수 있습니다. 클라우드 네이티브 애플리케이션의 사용이 늘어나면서 컨테이너와 쿠버네티스 보안 상태를 강화하는 것이 매우 중요해졌습니다.

Red Hat®은 모든 제품의 수명 전반에 걸쳐 오픈소스 소프트웨어의 유지 관리에 상당한 투자를 하고 있습니다. Red Hat은 제공하는 소프트웨어를 지원할 뿐 아니라 보안과 같은 중요 문제를 해결할 책임이 있습니다.

Red Hat Trusted Software Supply Chain은 조직이 처음부터 소프트웨어 개발 라이프사이클에 보안을 통합하도록 지원합니다. 적합한 보안 소프트웨어를 사용하는 조직은 공급망 시스템 내의 위험과 취약점으로부터 스스로를 보호할 수 있습니다. 적절한 보호 없이는 사용자, 고객 및 기타 이해관계자의 신뢰를 잃을 수도 있습니다. Red Hat Trusted Software Supply Chain을 활용하는 고객은 검증된 플랫폼, 신뢰할 수 있는 콘텐츠, 실시간 보안 검사 및 문제 해결 기능을 사용하여 소프트웨어를 코딩, 빌드 및 모니터링할 수 있습니다.

Red Hat OpenShift®는 DevSecOps를 자동화하고 개발 주기 초기와 전반에 보안을 통합하여 시프트 레프트 접근 방식을 지원합니다. 즉시 사용 가능한 다양한 개발자 툴, CI/CD 기능, 보안 중심 접근 방식으로 안전하고 효율적인 소프트웨어 공급망을 보장합니다. 기업이 대규모로 혁신적인 애플리케이션을 빌드, 배포, 실행, 관리하고 보안을 제공하도록 지원하는 통합 쿠버네티스 기반 애플리케이션 플랫폼입니다.

Red Hat Advanced Cluster Security for Kubernetes는 보안을 초기에 통합(‘시프트 레프트’)하고 DevSecOps 모범 사례를 자동화합니다. 이 플랫폼은 모든 쿠버네티스 환경과 연동되며 DevOps 및 보안 툴과 통합되어 팀이 공급망, 인프라, 워크로드를 운영화하고 더욱 안전하게 보호할 수 있습니다.

Red Hat Ansible Automation Platform은 규모에 맞게 IT 자동화를 구축하고 운영하기 위한 일관된 엔터프라이즈 프레임워크를 제공하는 동시에 소프트웨어 개발 라이프사이클 전반에서 보안을 최우선으로 고려합니다. 이를 통해 팀은 전사적으로 보안과 컴플라이언스를 자동화하고 인증된 오토메이션 콘텐츠를 사용하여 유기적으로 위협에 대응하며 24시간 지원을 받을 수 있습니다. 또한 Red Hat Ansible은 Red Hat과 Red Hat의 보안 기술 파트너가 함께 지원하는 다양한 통합 보안을 제공합니다.