요즘 대부분의 조직은 일종의 DevOps를 실행하고 있습니다. 일부는 특히 CI / CD (지속적 통합 / 지속적 배포) 파이프 라인이 설정된 경우 놀라운 릴리스 속도를 달성하고 있습니다. 그러나 일반 소비자조차도 출시 속도가 항상 더 높은 애플리케이션 품질을 수반하는 것은 아니라는 것을 알 수 있습니다. 그러나 Agile, DevOps 및 CI / CI의 요점은 더 나은 품질의 코드를 더 빠르게 생성하는 것입니다.
비교적 새로운 한 가지 중요한 품질 문제는 애플리케이션 보안입니다 (적어도 단위 테스트와 비교할 때). 소프트웨어 개발 수명주기 (SDLC) 후반에 취약성 검사를 수행하는 것은 매우 부적절합니다.왼쪽으로 이동”품질 관행이 수용되었습니다. 이 용어에 익숙하지 않은 경우 왼쪽으로 이동한다는 것은 개발자가 기존보다 코드 품질에 대해 더 책임을지게하는 것을 의미합니다. 실습에는 성능 테스트 및 보안 테스트. 그러나 근본적으로 기업이해야 할 일은 보안을 코드에보다 포괄적으로 적용하는 것입니다.
DevOps 및 Security가 사일로에서 작업 할 때 더 안전한 코드를 생성하는 것은 릴리스주기를 늦추고 공통 언어 또는 공통 관행의 이점이 없기 때문에 수행하기 어렵습니다. 사이버 보안 위협의 수와 유형이 증가함에 따라 DevOps 팀은 점점 더 DevSecOps 팀 때문에 그들의 회사는 보안 코드를 생성해야합니다.
보안에 대한 SDLC 접근 방식
XNUMX 년 이상 소프트웨어 팀은 소프트웨어의 품질을 향상시키려는 경우 "조기 및 자주 테스트"하라는 권고를 받았습니다. 성명서에서 의도 한 것은 제품 품질을 보장하는 가장 좋은 방법이기 때문에 SDLC 전체에서 테스트하는 것입니다.
교차 기능 Agile 및 DevOps 관행의 결과로 개발자, 테스터 및 ITOps는 이제 품질이 여정의 중단이 아니라 여정의 일부임을 이해합니다.
보안은 사이버 공격의 증가로 인해 상대적으로 새로운 개발입니다 (예 : 단위 테스트에 비해). 적절한 애플리케이션 보안을 달성하려면 보안 팀의 누군가가 DevSecOps 팀에서 적극적인 역할을 수행하여 SDLC의 모든 단계에 보안을 설계 할 수 있어야합니다. 요점은 취약성을 최대한 빨리 포착하는 것입니다. 그 이유는 수명주기 후반에 비해 수정하는 것이 더 빠르고 저렴하기 때문입니다. 더 중요한 것은 디자이너, 개발자, 테스터, QA 엔지니어, 보안 전문가, ITOps 엔지니어 등 다양한 역할을 가진 사람들이이를 포착 할 기회를 가질 때 애플리케이션 취약성의 수를 줄일 수 있다는 것입니다. 물론이 모든 것을 용이하게하는 도구가 존재하지만 도구만으로는 효과적인 DevSecOps 관행과 동일하지 않습니다.
책임은 "사물"입니다.
특히 AI의 부상과 함께 AI 윤리, 디지털 윤리 및 기술 윤리에 대한 논의가 더 많아졌습니다. 그 중 일부는 책임과 책임과 관련이 있습니다. 문제가 발생하면 누구에게 책임을 져야합니까? 제작자? 사용자? 구성 요소 공급자? 구매를 승인 한 사람은? 대답하기 쉬운 질문이 아닙니다.
비슷한 추세가 이미 소프트웨어 프로젝트 관리 수준에서 전개되었으며이를 실현하기위한 프레임 워크가 이미 있습니다. 그것은 RACI 프로젝트 역할과 책임을 정의하고 문서화하는 매트릭스.
RACI는 책임감 있고, 책임감 있고, 자문을 받고, 정보를 제공하며, 각각은 이해 관계자의 역할입니다. 특히 "책임있는"사람들이 무언가를하거나 무언가를 승인합니다. "책임있는"사람들이 프로젝트를 소유합니다. "컨설팅 된"사람들은 입력이 포함되어야하는 사람들입니다. "정보를 알고있는"사람들은 그저 루프에 머물러 있으면됩니다.
RACI 행렬은 실제로 테이블로 구성됩니다. 행은 특정 작업, 결정 또는 이정표. 열에는 왼쪽에서 오른쪽으로 프로젝트와 관련된 다양한 작업이 포함되며 프로젝트에 포함 된 작업, 이해 관계자의 이름, 이해 관계자의 전문 역할 (프로젝트 후원자, 비즈니스 분석가, 프로젝트 관리자, 기술 설계자 및 응용 프로그램 개발자)이 있습니다. 각 전문 역할 아래에있는 셀에는 특정 작업과 관련하여 개인의 역할이 무엇인지에 따라 R, A, C 또는 I의 RACI 역할 지정이 포함됩니다.
RACI 매트릭스의 장점은 프로젝트 팀이보다 효과적으로 의사 소통하고 각 개인이해야 할 일을 이해하지 못하여 발생하는 모든 마찰을 피할 수 있도록 지원한다는 것입니다. 사이버 보안과 관련하여 이러한 종류의 명확성을 달성하는 것이 필수적입니다.
공급망 책임에는 SCA, SBOM이 필요합니다.
오늘날의 애플리케이션에는 그 어느 때보 다 많은 타사 소프트웨어 구성 요소, 라이브러리 및 API가 포함되어 있습니다. 그들 중 일부는 오픈 소스이고 일부는 상용 제품입니다. 결과적으로 회사는 자신이 만들지 않은 소프트웨어에 대해 책임을 져야 할 수 있습니다. 이것이 바로 소프트웨어 구성 분석 (SCA) 소프트웨어가 매우 중요한 이유입니다. 또한 가지고있는 것이 좋습니다 소프트웨어 BOM (SBOM) 애플리케이션에서 사용되는 구성 요소, 출처, 종속성, 알려진 취약점, 버전 등의 살아있는 문서입니다.
SCA와 SBOM은 모두 DevSecOps 파이프 라인에 포함되어야합니다. SBOM은 오늘날 소프트웨어의 복잡성을 감안할 때 필요한 자동화 된 방식으로 생성 및 유지 관리 할 수 있습니다. 이렇게하면 보안 사고 후 감사가있을 경우 SCA와 SBOM 모두 증거를 훨씬 쉽게 생성 할 수 있습니다.
코인 스마트. 유로파 최고의 비트 코인-보르 스
출처 : https://www.cshub.com/executive-decisions/articles/devsecops-isnt-optional-anymore
