소프트웨어 개발은 전 세계적으로 점점 더 많은 사람들이 참여하고 있는 관행입니다. 소프트웨어를 구축하는 회사와 개인이 있으며 일부는 독점, 일부는 무료 또는 오픈 소스이며 일부는 이 둘을 융합한 것입니다. 사용자 또는 해당 소프트웨어의 보안에 대한 위협은 무언가가 완료되었다고 선언되고 프로덕션으로 배송되자마자 갑자기 실현되지 않으므로, 조금씩 발생할 수 있는 보안 위험을 관리하는 데 도움이 되는 보안 관행에 대해 이야기할 적절한 시기인 것 같습니다. 개발 과정에서 귀하의 소프트웨어. 다음을 포함하여 여러 SSDLC(보안 소프트웨어 개발 수명 주기) 프레임워크가 있습니다. OWASP, CISA및 NIST (SSDF). 이 기사에서는 소프트웨어 개발에 내재된 위험을 관리하는 데 도움이 되는 몇 가지 사례를 강조하기 위해 이들 모두에서 일부를 빌려보겠습니다. 자신에게는 그런 일이 일어날 수 없다고 잘못된 안도감을 갖고 생활하지 마십시오. Check Point 2023 상반기 사이버 보안 보고서에 따르면 전 세계 사이버 공격이 8% 급증한 것으로 나타났습니다. 2022년 이후에도 추세는 반전될 것 같지 않습니다.
소프트웨어 개발 수명주기란 무엇입니까?
소프트웨어 개발자는 소프트웨어를 빠르고 정확하며 안전하게 구축하는 것을 목표로 합니다. 물론 항상 세 가지를 모두 얻을 수는 없습니다. 시간이 지남에 따라 개발 프로세스는 모든 소프트웨어 개발에 적합할 수 있는 여러 단계로 나누어졌습니다. 이러한 단계는 다음과 같이 분류될 수 있습니다.
- 요구 사항 분석 – 우리는 무엇을 구축할 것이며 그 이유는 무엇입니까?
- 계획 – 일반적인 용어로 어떻게 구축할 것인가
- 소프트웨어 디자인 – 건축 디자인과 같은 구체적인 측면에서 어떻게 구축할 것인지
- 소프트웨어 개발 – 소프트웨어 작성 및 컴파일
- 지원 – 계획대로 작동하는지 확인
- 전개 – 최종 사용자가 사용할 수 있도록 배송하거나 게시합니다.
이 주기에는 몇 가지 다른 버전이 있지만 전반적으로 매우 유사합니다. 주기는 일회성이 아니라는 점을 기억하는 것이 중요합니다. 일반적으로 클라이언트에 제공하거나 클라우드에 게시한 후에는 끝나지 않습니다. 재설계(원래로 돌아가기)가 필요할 수 있는 처리해야 할 문제, 수정해야 할 버그, 추가하고 싶은 기능 등이 거의 항상 있습니다. 또한 여러 단계를 병렬로 진행하거나 중간 단계에서 중지하여 더블백을 수행할 수도 있습니다. 어떤 단계도 본질적으로 보안 중심이 아니기 때문에 보안이 개발 프로세스를 지속적으로 따라잡아야 하며 오늘날의 바쁜 개발 속도에서는 충분하지 않습니다.
SDLC 보안의 중요성
보안 소프트웨어 개발은 보안을 프로세스에 대한 추가 기능으로 취급하지 않고 프로세스의 모든 단계에 보안 고려 사항을 포함하는 것을 목표로 합니다. 이러한 방식으로 프로젝트 요구 사항에 대해 생각하고, 아키텍처를 계획하고, 필요한 빌딩 블록과 인프라를 고려하고, 코드를 개발하는 등 현재 진행 중인 프로세스의 어떤 단계에 관계없이 보안을 항상 고려해야 합니다. 이 접근법은 때때로 왼쪽 시프트 보안 보다 더 전체적인 접근 방식으로 피할 수 있습니다.
여기서 Shift-Left는 개발 프로세스 전반에 걸쳐 보안 문제를 분산하고 보안 설계, 구현 및 테스트에 개발자를 참여시키는 것을 의미합니다.
보안 문제에 대해 실제로 생각해 본 적이 없는 개발자가 갑자기 보안 문제를 처리해야 한다는 것은 겁이 날 수 있습니다. 요구사항을 잘 정의된 여러 모범 사례로 나누면 처리하기가 훨씬 더 쉽습니다. 새로운 IDE를 선택하는 것과 같다고 생각할 수 있습니다.
요구 사항이 더 잘 정의되고 사용할 수 있는 자동화 및 포괄적인 도구가 많을수록 작업이 더 쉬워집니다.
SDLC 보안 모범 사례
특별한 순서 없이 개발 프로세스를 보호하는 데 도움이 되는 몇 가지 모범 사례는 다음과 같습니다.
트레이닝 – 많은 개발자들은 보안 고려 사항을 적용하고 자신이 작성 중인 코드를 테스트하는 작업이 불평등하다고 느낄 것입니다. 대부분의 개발자는 오염된 입력 데이터를 백엔드에 두면 잘 알려진 "드롭 테이블"과 마찬가지로 원격 코드 활성화가 발생할 수 있다는 것을 알고 있습니다. 그러나 버퍼 오버플로 테스트나 3차(또는 그 이상) 종속성에 대한 취약점 검색에 익숙한 사람은 거의 없습니다. 개발자는 교육을 통해 이러한 지식 격차를 줄일 수 있습니다. 개발자는 보안 문제와 잠재적인 취약성에 대해 더 깊이 이해할 때 보안 문제를 일상적인 코딩 및 테스트에 통합할 수 있는 능력을 더 잘 갖추게 됩니다. 또한 코드를 작성하고 해당 기능에 대해 잘 알고 있는 개발자가 보안 허점을 고려하고 이에 따라 테스트를 계획하는 것이 훨씬 더 합리적입니다.
스캐닝 – 다양한 유형의 스캔을 사용하여 코드를 전반적으로 더욱 안전하게 만들 수 있습니다. 정적, 동적 및 대화형 분석이 그 중 일부입니다. 정적 분석은 소스 코드에서 명백한 코딩 결함이나 가능한 보안 취약점을 찾습니다. 잠재적인 취약점, 안전하지 않은 코드 관행 및 코딩 표준 위반을 찾는 데 사용할 수 있습니다. 코드 구문만 검사하므로 런타임 이벤트는 고려하지 않습니다. 동적 분석은 애플리케이션이 실행되는 동안 보안 결함, 코딩 결함 및 기타 문제를 찾습니다. 이는 메모리 누수, 수준 이하의 작업 및 불안정할 수 있는 입력 또는 프로세스를 식별하는 데 사용할 수 있습니다. 이러한 유형의 테스트는 특정 시간에 특정 입력을 사용하여 수행되므로 테스트의 품질은 전적으로 테스트를 고안한 개인에 따라 달라집니다. 목표는 사용자가 문제를 발견하기 전에 문제를 찾는 것입니다. 대화형 분석은 애플리케이션을 검사하여 잠재적인 보안 결함 및 기타 주요 문제를 찾습니다. 가능한 취약점, 유용성 문제 및 사용자 인터페이스 문제를 찾을 수 있습니다. 더욱 포괄적인 스캐닝 도구를 활용할수록 더 효과적으로 보호받을 수 있지만, 물론 개발 속도가 저하됩니다. 각 응용 프로그램은 고유하므로 적절한 스캔 양과 원하는 개발 속도 사이의 균형을 찾는 것은 사용자의 몫입니다. 또한 애플리케이션의 전체 SBOM을 생성하고 해당 데이터 소스에 다양한 스캔 및 보고서를 적용하는 것이 좋습니다. 앱의 SBOM 레거시를 갖는 것은 다양한 보안상의 이유로 매우 중요할 수 있는 매우 상세한 구성 요소 및 패키지 정보를 유지하는 좋은 방법입니다.
코드 검토 – 소스 코드를 검사하여 활성 개발 브랜치와 결합하기 전에 보안 결함, 코딩 실수 및 기타 소프트웨어 결함을 찾는 것을 코드 검토라고 합니다. 일반적으로 코드를 작성한 사람보다 더 전문적인 지식을 갖춘 개발자가 이 검토를 수행합니다. 이러한 검토는 코드가 잘 작성되었고 애플리케이션이 안전한지 확인하는 데 도움이 될 수 있습니다. 또한 전체 코드 베이스에 걸쳐 단일 표준 및 코딩 규칙(예: 함수 및 변수 이름)을 유지하도록 지원합니다.
최소한 두 쌍의 눈으로 검토한 후 코드를 메인 브랜치에 통합하는 것이 모범 사례로 간주됩니다. 물론 코드를 작성한 개발자는 첫 번째 눈입니다. 팀 리더와 같이 고도로 숙련된 엔지니어라도 다른 사람이 자신의 코드를 평가하도록 하는 것이 도움이 될 수 있습니다. 최소한 한 명 이상의 사람이 코드의 각 섹션에 익숙해지도록 보장합니다. 스트레스가 크거나 위기에 처한 시기에 사람들은 이 요소를 포기하는 것을 고려할 수도 있다는 점을 명심하십시오. 가능하다면 이 규칙을 우회할 수 없도록 CI/CD의 하드 코딩된 요소로 추가하는 것이 좋습니다.
지원 – 문제가 발생하기 전에 보안 결함을 발견하기 위해 코드를 테스트하는 것이 얼마나 중요한지 말할 필요는 없습니다. 대부분의 코드 프로젝트는 복잡하고 상호 연결되어 있으므로 하나의 작은 간격이 결국 전체 코드 기반의 보안에 어떤 영향을 미칠 수 있는지 예측하는 것은 불가능합니다.
자동화된 테스트를 작성할 때 최근 생성된 코드의 기능은 물론 코드 베이스의 다른 부분과의 중요한 백엔드 및 프런트엔드 상호 작용을 고려하세요.
SQL 주입, 사이트 간 스크립팅, 안전하지 않은 데이터 저장, 부적절한 메모리 할당(버퍼 오버플로를 일으킬 수 있음)과 같은 취약점은 일반적으로 테스트에서 해결되는 보안 문제의 예입니다. 테스트에서는 메모리 누수, 느리거나 신뢰할 수 없는 성능 및 유용성을 해결해야 합니다. 테스트는 자동으로 이루어져야 하며 CI/CD 파이프라인에 통합되어 단위 테스트와 통합 테스트를 모두 거치지 않으면 새 버전이나 업데이트가 게시될 수 없습니다.
독립적인 펜 테스트 – 누구도 모든 것을 생각할 수는 없고, 개발자로서 우리가 작성한 코드에 대해 사각지대가 생길 때가 있습니다. 코드 검토와 마찬가지로 독립적인 펜 테스트를 통해 우리가 수행한 작업과 앱과 사용자를 보호하기 위해 취한 예방 조치를 비판적으로 검토할 수 있는 새로운 접근 방식과 또 다른 시각을 제공합니다. 이러한 테스트는 최소 1년에 한 번 권장되며 인프라 평가와 앱 취약성을 통합해야 합니다.
오픈소스를 안전하게 사용하세요 – 오늘날 개발 중인 거의 모든 소프트웨어에는 어느 정도 오픈 소스 소프트웨어가 포함되어 있습니다. 오픈 소스 구성 요소는 직접적으로 또는 일시적인 종속성을 통해 애플리케이션에 취약점을 가져오는 주요 원인 중 일부입니다. 또한, 귀하를 위험에 빠뜨릴 수 있는 것은 귀하가 사용하는 라이브러리뿐만 아니라 오래된 라이브러리를 업데이트하지 못하거나 귀하에게 영향을 미칠 수 있는 최신 게시된 CVE를 최신 상태로 유지하지 못하는 것입니다. 조직에서 사용할 수 있도록 승인된 오픈소스 패키지 목록을 만들고 지속적으로 확인하고 업데이트하는 것이 좋습니다. 단지 테스트일지라도 개발자가 원하는 패키지를 추가하지 못하게 하면 처리해야 하는 취약점의 수를 줄이는 데 도움이 될 수 있습니다.
취약점이 공격으로 바뀌지 않도록 하세요 – 취약점이 없는 코드베이스는 거의 없습니다. 괜찮은 스캔이라면 수백에서 수천 개까지 나타날 것입니다. 그것들을 모두 제거하는 것은 불가능합니다. 취약점은 악용이 아니라는 점을 기억하는 것도 중요합니다. 발견한 취약점이 악용 가능한 위협이 아닌지 확인하고 이 목록을 지속적으로 업데이트하기 위한 필터링 프로세스가 있는지 확인하십시오. 이러한 방식으로 최신 CVE에 대해 우려하는 제3자 또는 사용자를 진정시켜 애플리케이션에 전혀 영향을 미치지 않을 수 있습니다.
보안은 사고방식에서 시작됩니다
개발자, 프레임워크, 코딩 언어만큼 소프트웨어를 개발하는 방법도 다양할 것입니다. 즉, 사용 중인 언어, 분야 또는 IDE에 관계없이 관련성이 있는 개발 프로세스를 보호하기 위한 모범 사례를 찾는 것이 쉽지 않습니다. '대체할 수 없는 차세대 보안 도구'로 관심을 끌고 있는 수많은 도구, 일부 독점 도구, 일부 무료 도구를 넘어, 사용할 수 있는 가장 중요한 보안 도구는 사고방식입니다.
디자인 선택, 아키텍처, 스토리지에 대해 생각해 보세요. 사용자 기반이 기하급수적으로 증가하는 옵션을 고려해 보셨나요? 코드베이스 및 인프라의 다양한 부분에 대해 액세스 권한을 적절하게 분할했습니까? 데이터나 비밀에 대한 표적 공격과 소프트웨어 공급망 '간접' 공격을 모두 고려하셨나요?
애플리케이션을 계획하기 전에 이러한 모든 질문과 그 이상을 고려해야 하며, 코드베이스와 앱이 성장하고 발전함에 따라 정기적으로 재검사해야 합니다.
모든 소프트웨어에서 가장 취약한 부분은 이를 실행하는(또는 작성하는) 사람이라는 것이 공리로 간주됩니다. 귀하의 애플리케이션, 소프트웨어 또는 코드 라이브러리가 새로운 사이버 공격의 증가하는 통계에 포함되도록 하지 마십시오. 적절한 계획, 도구 및 자동화를 통해 사이버 위험 관리, 개발 수명 주기 보호, 잘 문서화되고 포괄적이며 효율적인 코드 생성 사이에서 적절한 균형을 찾을 수 있습니다.