코드 시리즈로 보안 인프라를 정복하는 코더 - 신뢰할 수 없는 출처의 구성 요소 사용
Infrastructure as Code 시리즈가 거의 끝나갈 무렵이지만 IaC 보안 여정에서 여러분과 같은 개발자를 도울 수 있어서 정말 좋았습니다.
챌린지를 플레이해 보셨나요?지금까지 어떤 점수가 나왔나요?시작하기 전에 신뢰할 수 없는 출처의 구성 요소를 사용할 때 발생할 수 있는 함정에 대해 이미 얼마나 알고 있는지 살펴보겠습니다.
아직 해야 할 일이 있나요?계속 읽어보세요:
오늘날 우리가 집중적으로 살펴볼 취약점 유발 행위는 신뢰할 수 없는 출처의 코드를 사용하는 것인데, 이는 겉보기에 무해해 보이지만 큰 문제를 일으키고 있습니다.오픈 소스 코드와 리소스를 사용하면 많은 이점이 있습니다.일반적으로 전문가들이 자신의 아이디어, 작업, 완성된 코드를 GitHub와 같은 저장소에 제공하여 프로그램이나 앱이 제대로 작동하도록 하는 데 어려움을 겪고 있는 다른 사람들이 사용할 수 있도록 합니다.완성된 코드를 사용하여 프로그램 기능을 관리하면 개발자가 새 애플리케이션을 만들어야 할 때마다 처음부터 다시 만들지 않아도 됩니다.
그러나 신뢰할 수 없거나 알려지지 않았거나 잠재적으로 위험한 출처의 코드 스니펫을 사용하는 것은 많은 위험을 수반합니다.사실 신뢰할 수 없는 출처의 코드를 사용하는 것은 크고 작은 보안 취약점이 보안 애플리케이션에 침투하는 가장 일반적인 방법 중 하나입니다.이러한 취약점은 제작자가 실수로 유발한 경우도 있습니다.잠재적 공격자가 악성 코드를 작성한 사례도 있습니다.그런 다음 해당 코드를 공유하여 피해자가 자신의 애플리케이션에 코드를 삽입하도록 유혹할 수 있도록 합니다.
신뢰할 수 없는 출처의 코드를 사용하는 것이 왜 위험한가요?
개발자가 급해서 개발 중인 애플리케이션을 구성해야 한다고 가정해 보겠습니다.이는 까다로운 프로세스일 수 있습니다.따라서 가능한 모든 구성을 알아내느라 많은 시간을 소비하는 대신 Google 검색을 통해 겉보기에 완벽해 보이는 구성 파일을 이미 완성한 사람을 찾습니다.개발자가 코드를 작성한 사람에 대해 아는 것이 없더라도 새 애플리케이션에 코드를 추가하는 것은 비교적 쉽습니다.Docker 환경에서는 다음 두 줄을 사용하여 수행할 수 있습니다.
cd /etc/apache2/사이트 실행 가능/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
이제 Docker 이미지는 타사 구성 파일을 동적으로 가져옵니다.그리고 파일을 테스트한 결과 당시에는 문제가 없는 것으로 확인되더라도 이제 포인터가 새 애플리케이션의 코드에 포함되어 있다는 사실은 영구적인 종속성이 존재한다는 것을 의미합니다.며칠, 몇 주 또는 몇 달이 지나면 원래 작성자나 코드 저장소를 손상시킨 공격자에 의해 파일이 변경될 수 있습니다.갑자기 공유된 구성 파일이 응용 프로그램이 의도한 것과 매우 다르게 작동하도록 지시하여 권한 없는 사용자에게 액세스 권한을 부여하거나 직접 데이터를 훔쳐 유출할 수도 있습니다.
공유 리소스를 사용하는 더 나은 방법
조직에서 외부 소스의 코드 사용을 허용하는 경우 안전하게 수행되도록 하는 프로세스를 마련해야 합니다.외부 코드의 활용 가능성을 평가할 때는 반드시 보안 링크를 사용하여 공식 소스로부터 구성 요소를 구해야 합니다.그런 경우에도 외부 소스에 연결하여 코드를 가져와서는 안 됩니다. 그러면 프로세스를 제어할 수 없게 되기 때문입니다.대신 승인된 코드를 안전한 라이브러리로 가져와 보호된 위치에서만 사용해야 합니다.따라서 Docker 환경에서는 코드가 다음과 같이 보일 것입니다.
복사 src/config/default-ssl.conf /etc/apache2/sites-available/
원격 타사 구성 파일에 의존하는 대신 해당 파일의 로컬 복사본을 사용합니다.이렇게 하면 예상치 못한 변경이나 악의적인 변경을 방지할 수 있습니다.
보안 코드 라이브러리를 사용하는 것 외에도 소프트웨어 라이프사이클 전반에 걸쳐 구성 요소를 지속적으로 모니터링할 수 있는 패치 관리 프로세스를 마련해야 합니다.또한 NVD 또는 CVE와 같은 도구를 사용하여 모든 클라이언트 및 서버 측 구성 요소에 보안 경고가 있는지 확인해야 합니다.마지막으로, 외부 코드와 함께 사용할 수 있는 사용하지 않거나 불필요한 종속성 및 기능을 제거하세요.
이러한 단계를 따르면 개발자는 실수로 애플리케이션 및 코드에 취약점을 유발하지 않고 외부 리소스를 더 안전하게 사용할 수 있습니다.
확인해 보세요 시큐어 코드 워리어 이 취약성에 대한 자세한 정보와 다른 보안 결함으로 인한 피해로부터 조직과 고객을 보호하는 방법을 알아보려면 블로그 페이지를 참조하십시오.또한 다음과 같은 방법도 있습니다. 데모 사용해 보기 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 Secure Code Warrior 교육 플랫폼의 IaC 과제에 대해 알아보십시오.
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
Infrastructure as Code 시리즈가 거의 끝나갈 무렵이지만 IaC 보안 여정에서 여러분과 같은 개발자를 도울 수 있어서 정말 좋았습니다.
챌린지를 플레이해 보셨나요?지금까지 어떤 점수가 나왔나요?시작하기 전에 신뢰할 수 없는 출처의 구성 요소를 사용할 때 발생할 수 있는 함정에 대해 이미 얼마나 알고 있는지 살펴보겠습니다.
아직 해야 할 일이 있나요?계속 읽어보세요:
오늘날 우리가 집중적으로 살펴볼 취약점 유발 행위는 신뢰할 수 없는 출처의 코드를 사용하는 것인데, 이는 겉보기에 무해해 보이지만 큰 문제를 일으키고 있습니다.오픈 소스 코드와 리소스를 사용하면 많은 이점이 있습니다.일반적으로 전문가들이 자신의 아이디어, 작업, 완성된 코드를 GitHub와 같은 저장소에 제공하여 프로그램이나 앱이 제대로 작동하도록 하는 데 어려움을 겪고 있는 다른 사람들이 사용할 수 있도록 합니다.완성된 코드를 사용하여 프로그램 기능을 관리하면 개발자가 새 애플리케이션을 만들어야 할 때마다 처음부터 다시 만들지 않아도 됩니다.
그러나 신뢰할 수 없거나 알려지지 않았거나 잠재적으로 위험한 출처의 코드 스니펫을 사용하는 것은 많은 위험을 수반합니다.사실 신뢰할 수 없는 출처의 코드를 사용하는 것은 크고 작은 보안 취약점이 보안 애플리케이션에 침투하는 가장 일반적인 방법 중 하나입니다.이러한 취약점은 제작자가 실수로 유발한 경우도 있습니다.잠재적 공격자가 악성 코드를 작성한 사례도 있습니다.그런 다음 해당 코드를 공유하여 피해자가 자신의 애플리케이션에 코드를 삽입하도록 유혹할 수 있도록 합니다.
신뢰할 수 없는 출처의 코드를 사용하는 것이 왜 위험한가요?
개발자가 급해서 개발 중인 애플리케이션을 구성해야 한다고 가정해 보겠습니다.이는 까다로운 프로세스일 수 있습니다.따라서 가능한 모든 구성을 알아내느라 많은 시간을 소비하는 대신 Google 검색을 통해 겉보기에 완벽해 보이는 구성 파일을 이미 완성한 사람을 찾습니다.개발자가 코드를 작성한 사람에 대해 아는 것이 없더라도 새 애플리케이션에 코드를 추가하는 것은 비교적 쉽습니다.Docker 환경에서는 다음 두 줄을 사용하여 수행할 수 있습니다.
cd /etc/apache2/사이트 실행 가능/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
이제 Docker 이미지는 타사 구성 파일을 동적으로 가져옵니다.그리고 파일을 테스트한 결과 당시에는 문제가 없는 것으로 확인되더라도 이제 포인터가 새 애플리케이션의 코드에 포함되어 있다는 사실은 영구적인 종속성이 존재한다는 것을 의미합니다.며칠, 몇 주 또는 몇 달이 지나면 원래 작성자나 코드 저장소를 손상시킨 공격자에 의해 파일이 변경될 수 있습니다.갑자기 공유된 구성 파일이 응용 프로그램이 의도한 것과 매우 다르게 작동하도록 지시하여 권한 없는 사용자에게 액세스 권한을 부여하거나 직접 데이터를 훔쳐 유출할 수도 있습니다.
공유 리소스를 사용하는 더 나은 방법
조직에서 외부 소스의 코드 사용을 허용하는 경우 안전하게 수행되도록 하는 프로세스를 마련해야 합니다.외부 코드의 활용 가능성을 평가할 때는 반드시 보안 링크를 사용하여 공식 소스로부터 구성 요소를 구해야 합니다.그런 경우에도 외부 소스에 연결하여 코드를 가져와서는 안 됩니다. 그러면 프로세스를 제어할 수 없게 되기 때문입니다.대신 승인된 코드를 안전한 라이브러리로 가져와 보호된 위치에서만 사용해야 합니다.따라서 Docker 환경에서는 코드가 다음과 같이 보일 것입니다.
복사 src/config/default-ssl.conf /etc/apache2/sites-available/
원격 타사 구성 파일에 의존하는 대신 해당 파일의 로컬 복사본을 사용합니다.이렇게 하면 예상치 못한 변경이나 악의적인 변경을 방지할 수 있습니다.
보안 코드 라이브러리를 사용하는 것 외에도 소프트웨어 라이프사이클 전반에 걸쳐 구성 요소를 지속적으로 모니터링할 수 있는 패치 관리 프로세스를 마련해야 합니다.또한 NVD 또는 CVE와 같은 도구를 사용하여 모든 클라이언트 및 서버 측 구성 요소에 보안 경고가 있는지 확인해야 합니다.마지막으로, 외부 코드와 함께 사용할 수 있는 사용하지 않거나 불필요한 종속성 및 기능을 제거하세요.
이러한 단계를 따르면 개발자는 실수로 애플리케이션 및 코드에 취약점을 유발하지 않고 외부 리소스를 더 안전하게 사용할 수 있습니다.
확인해 보세요 시큐어 코드 워리어 이 취약성에 대한 자세한 정보와 다른 보안 결함으로 인한 피해로부터 조직과 고객을 보호하는 방법을 알아보려면 블로그 페이지를 참조하십시오.또한 다음과 같은 방법도 있습니다. 데모 사용해 보기 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 Secure Code Warrior 교육 플랫폼의 IaC 과제에 대해 알아보십시오.
Infrastructure as Code 시리즈가 거의 끝나갈 무렵이지만 IaC 보안 여정에서 여러분과 같은 개발자를 도울 수 있어서 정말 좋았습니다.
챌린지를 플레이해 보셨나요?지금까지 어떤 점수가 나왔나요?시작하기 전에 신뢰할 수 없는 출처의 구성 요소를 사용할 때 발생할 수 있는 함정에 대해 이미 얼마나 알고 있는지 살펴보겠습니다.
아직 해야 할 일이 있나요?계속 읽어보세요:
오늘날 우리가 집중적으로 살펴볼 취약점 유발 행위는 신뢰할 수 없는 출처의 코드를 사용하는 것인데, 이는 겉보기에 무해해 보이지만 큰 문제를 일으키고 있습니다.오픈 소스 코드와 리소스를 사용하면 많은 이점이 있습니다.일반적으로 전문가들이 자신의 아이디어, 작업, 완성된 코드를 GitHub와 같은 저장소에 제공하여 프로그램이나 앱이 제대로 작동하도록 하는 데 어려움을 겪고 있는 다른 사람들이 사용할 수 있도록 합니다.완성된 코드를 사용하여 프로그램 기능을 관리하면 개발자가 새 애플리케이션을 만들어야 할 때마다 처음부터 다시 만들지 않아도 됩니다.
그러나 신뢰할 수 없거나 알려지지 않았거나 잠재적으로 위험한 출처의 코드 스니펫을 사용하는 것은 많은 위험을 수반합니다.사실 신뢰할 수 없는 출처의 코드를 사용하는 것은 크고 작은 보안 취약점이 보안 애플리케이션에 침투하는 가장 일반적인 방법 중 하나입니다.이러한 취약점은 제작자가 실수로 유발한 경우도 있습니다.잠재적 공격자가 악성 코드를 작성한 사례도 있습니다.그런 다음 해당 코드를 공유하여 피해자가 자신의 애플리케이션에 코드를 삽입하도록 유혹할 수 있도록 합니다.
신뢰할 수 없는 출처의 코드를 사용하는 것이 왜 위험한가요?
개발자가 급해서 개발 중인 애플리케이션을 구성해야 한다고 가정해 보겠습니다.이는 까다로운 프로세스일 수 있습니다.따라서 가능한 모든 구성을 알아내느라 많은 시간을 소비하는 대신 Google 검색을 통해 겉보기에 완벽해 보이는 구성 파일을 이미 완성한 사람을 찾습니다.개발자가 코드를 작성한 사람에 대해 아는 것이 없더라도 새 애플리케이션에 코드를 추가하는 것은 비교적 쉽습니다.Docker 환경에서는 다음 두 줄을 사용하여 수행할 수 있습니다.
cd /etc/apache2/사이트 실행 가능/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
이제 Docker 이미지는 타사 구성 파일을 동적으로 가져옵니다.그리고 파일을 테스트한 결과 당시에는 문제가 없는 것으로 확인되더라도 이제 포인터가 새 애플리케이션의 코드에 포함되어 있다는 사실은 영구적인 종속성이 존재한다는 것을 의미합니다.며칠, 몇 주 또는 몇 달이 지나면 원래 작성자나 코드 저장소를 손상시킨 공격자에 의해 파일이 변경될 수 있습니다.갑자기 공유된 구성 파일이 응용 프로그램이 의도한 것과 매우 다르게 작동하도록 지시하여 권한 없는 사용자에게 액세스 권한을 부여하거나 직접 데이터를 훔쳐 유출할 수도 있습니다.
공유 리소스를 사용하는 더 나은 방법
조직에서 외부 소스의 코드 사용을 허용하는 경우 안전하게 수행되도록 하는 프로세스를 마련해야 합니다.외부 코드의 활용 가능성을 평가할 때는 반드시 보안 링크를 사용하여 공식 소스로부터 구성 요소를 구해야 합니다.그런 경우에도 외부 소스에 연결하여 코드를 가져와서는 안 됩니다. 그러면 프로세스를 제어할 수 없게 되기 때문입니다.대신 승인된 코드를 안전한 라이브러리로 가져와 보호된 위치에서만 사용해야 합니다.따라서 Docker 환경에서는 코드가 다음과 같이 보일 것입니다.
복사 src/config/default-ssl.conf /etc/apache2/sites-available/
원격 타사 구성 파일에 의존하는 대신 해당 파일의 로컬 복사본을 사용합니다.이렇게 하면 예상치 못한 변경이나 악의적인 변경을 방지할 수 있습니다.
보안 코드 라이브러리를 사용하는 것 외에도 소프트웨어 라이프사이클 전반에 걸쳐 구성 요소를 지속적으로 모니터링할 수 있는 패치 관리 프로세스를 마련해야 합니다.또한 NVD 또는 CVE와 같은 도구를 사용하여 모든 클라이언트 및 서버 측 구성 요소에 보안 경고가 있는지 확인해야 합니다.마지막으로, 외부 코드와 함께 사용할 수 있는 사용하지 않거나 불필요한 종속성 및 기능을 제거하세요.
이러한 단계를 따르면 개발자는 실수로 애플리케이션 및 코드에 취약점을 유발하지 않고 외부 리소스를 더 안전하게 사용할 수 있습니다.
확인해 보세요 시큐어 코드 워리어 이 취약성에 대한 자세한 정보와 다른 보안 결함으로 인한 피해로부터 조직과 고객을 보호하는 방법을 알아보려면 블로그 페이지를 참조하십시오.또한 다음과 같은 방법도 있습니다. 데모 사용해 보기 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 Secure Code Warrior 교육 플랫폼의 IaC 과제에 대해 알아보십시오.
아래 링크를 클릭하고 이 리소스의 PDF를 다운로드하십시오.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
보고서 보기데모 예약
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Matias는 15년 이상의 소프트웨어 보안 경험을 가진 연구원이자 개발자입니다. 그는 Fortify 소프트웨어와 같은 회사와 자신의 회사를 위한 솔루션을 개발했습니다. Sensei 안전. 그의 경력을 통해, Matias는 상용 제품으로 주도하고 자신의 벨트 아래 10 개 이상의 특허를 자랑하는 여러 응용 프로그램 보안 연구 프로젝트를 주도하고있다. 마티아스는 책상에서 떨어져 있을 때 고급 응용 프로그램 보안 교육을 위한 강사로 일했습니다. courses RSA 컨퍼런스, 블랙 햇, 데프콘, BSIMM, OWASP AppSec 및 브루콘을 포함한 글로벌 컨퍼런스에서 정기적으로 강연합니다.
마티아스는 겐트 대학교에서 컴퓨터 공학 박사 학위를 취득했으며, 프로그램 난독화를 통해 응용 프로그램 보안을 연구하여 응용 프로그램의 내부 작동을 숨깁니다.
Infrastructure as Code 시리즈가 거의 끝나갈 무렵이지만 IaC 보안 여정에서 여러분과 같은 개발자를 도울 수 있어서 정말 좋았습니다.
챌린지를 플레이해 보셨나요?지금까지 어떤 점수가 나왔나요?시작하기 전에 신뢰할 수 없는 출처의 구성 요소를 사용할 때 발생할 수 있는 함정에 대해 이미 얼마나 알고 있는지 살펴보겠습니다.
아직 해야 할 일이 있나요?계속 읽어보세요:
오늘날 우리가 집중적으로 살펴볼 취약점 유발 행위는 신뢰할 수 없는 출처의 코드를 사용하는 것인데, 이는 겉보기에 무해해 보이지만 큰 문제를 일으키고 있습니다.오픈 소스 코드와 리소스를 사용하면 많은 이점이 있습니다.일반적으로 전문가들이 자신의 아이디어, 작업, 완성된 코드를 GitHub와 같은 저장소에 제공하여 프로그램이나 앱이 제대로 작동하도록 하는 데 어려움을 겪고 있는 다른 사람들이 사용할 수 있도록 합니다.완성된 코드를 사용하여 프로그램 기능을 관리하면 개발자가 새 애플리케이션을 만들어야 할 때마다 처음부터 다시 만들지 않아도 됩니다.
그러나 신뢰할 수 없거나 알려지지 않았거나 잠재적으로 위험한 출처의 코드 스니펫을 사용하는 것은 많은 위험을 수반합니다.사실 신뢰할 수 없는 출처의 코드를 사용하는 것은 크고 작은 보안 취약점이 보안 애플리케이션에 침투하는 가장 일반적인 방법 중 하나입니다.이러한 취약점은 제작자가 실수로 유발한 경우도 있습니다.잠재적 공격자가 악성 코드를 작성한 사례도 있습니다.그런 다음 해당 코드를 공유하여 피해자가 자신의 애플리케이션에 코드를 삽입하도록 유혹할 수 있도록 합니다.
신뢰할 수 없는 출처의 코드를 사용하는 것이 왜 위험한가요?
개발자가 급해서 개발 중인 애플리케이션을 구성해야 한다고 가정해 보겠습니다.이는 까다로운 프로세스일 수 있습니다.따라서 가능한 모든 구성을 알아내느라 많은 시간을 소비하는 대신 Google 검색을 통해 겉보기에 완벽해 보이는 구성 파일을 이미 완성한 사람을 찾습니다.개발자가 코드를 작성한 사람에 대해 아는 것이 없더라도 새 애플리케이션에 코드를 추가하는 것은 비교적 쉽습니다.Docker 환경에서는 다음 두 줄을 사용하여 수행할 수 있습니다.
cd /etc/apache2/사이트 실행 가능/ &&\
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
이제 Docker 이미지는 타사 구성 파일을 동적으로 가져옵니다.그리고 파일을 테스트한 결과 당시에는 문제가 없는 것으로 확인되더라도 이제 포인터가 새 애플리케이션의 코드에 포함되어 있다는 사실은 영구적인 종속성이 존재한다는 것을 의미합니다.며칠, 몇 주 또는 몇 달이 지나면 원래 작성자나 코드 저장소를 손상시킨 공격자에 의해 파일이 변경될 수 있습니다.갑자기 공유된 구성 파일이 응용 프로그램이 의도한 것과 매우 다르게 작동하도록 지시하여 권한 없는 사용자에게 액세스 권한을 부여하거나 직접 데이터를 훔쳐 유출할 수도 있습니다.
공유 리소스를 사용하는 더 나은 방법
조직에서 외부 소스의 코드 사용을 허용하는 경우 안전하게 수행되도록 하는 프로세스를 마련해야 합니다.외부 코드의 활용 가능성을 평가할 때는 반드시 보안 링크를 사용하여 공식 소스로부터 구성 요소를 구해야 합니다.그런 경우에도 외부 소스에 연결하여 코드를 가져와서는 안 됩니다. 그러면 프로세스를 제어할 수 없게 되기 때문입니다.대신 승인된 코드를 안전한 라이브러리로 가져와 보호된 위치에서만 사용해야 합니다.따라서 Docker 환경에서는 코드가 다음과 같이 보일 것입니다.
복사 src/config/default-ssl.conf /etc/apache2/sites-available/
원격 타사 구성 파일에 의존하는 대신 해당 파일의 로컬 복사본을 사용합니다.이렇게 하면 예상치 못한 변경이나 악의적인 변경을 방지할 수 있습니다.
보안 코드 라이브러리를 사용하는 것 외에도 소프트웨어 라이프사이클 전반에 걸쳐 구성 요소를 지속적으로 모니터링할 수 있는 패치 관리 프로세스를 마련해야 합니다.또한 NVD 또는 CVE와 같은 도구를 사용하여 모든 클라이언트 및 서버 측 구성 요소에 보안 경고가 있는지 확인해야 합니다.마지막으로, 외부 코드와 함께 사용할 수 있는 사용하지 않거나 불필요한 종속성 및 기능을 제거하세요.
이러한 단계를 따르면 개발자는 실수로 애플리케이션 및 코드에 취약점을 유발하지 않고 외부 리소스를 더 안전하게 사용할 수 있습니다.
확인해 보세요 시큐어 코드 워리어 이 취약성에 대한 자세한 정보와 다른 보안 결함으로 인한 피해로부터 조직과 고객을 보호하는 방법을 알아보려면 블로그 페이지를 참조하십시오.또한 다음과 같은 방법도 있습니다. 데모 사용해 보기 모든 사이버 보안 기술을 연마하고 최신 상태로 유지하기 위한 Secure Code Warrior 교육 플랫폼의 IaC 과제에 대해 알아보십시오.
목차
마티아스 마두는 보안 전문가, 연구원, CTO이자 Secure Code Warrior 의 공동 설립자입니다. 마티아스는 겐트 대학교에서 정적 분석 솔루션에 중점을 둔 애플리케이션 보안 박사 학위를 취득했습니다. 이후 미국의 Fortify에 입사하여 개발자의 보안 코드 작성을 지원하지 않고 코드 문제만 탐지하는 것만으로는 충분하지 않다는 것을 깨달았습니다. 이를 계기로 개발자를 지원하고 보안에 대한 부담을 덜어주며 고객의 기대를 뛰어넘는 제품을 개발하게 되었습니다. 팀 어썸의 일원으로 책상에 앉아 있지 않을 때는 RSA 컨퍼런스, 블랙햇, 데프콘 등의 컨퍼런스에서 무대에 올라 발표하는 것을 즐깁니다.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약다운로드
%20(1).avif)
.avif)
