코드 시리즈로 보안 인프라를 정복하는 코더 - 신뢰할 수 없는 출처의 구성 요소 사용
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 과제에 대해 알아보십시오.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
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 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
보고서 보기데모 예약
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
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 과제에 대해 알아보십시오.
목차
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior는 전체 소프트웨어 개발 라이프사이클에서 코드를 보호하고 사이버 보안을 최우선으로 생각하는 문화를 조성할 수 있도록 조직을 위해 여기 있습니다.AppSec 관리자, 개발자, CISO 또는 보안 관련 누구든 관계없이 조직이 안전하지 않은 코드와 관련된 위험을 줄일 수 있도록 도와드릴 수 있습니다.
데모 예약다운로드시작하는 데 도움이 되는 리소스
%20(1).avif)
.avif)
Threat Modeling with AI: Turning Every Developer into a Threat Modeler
Walk away better equipped to help developers combine threat modeling ideas and techniques with the AI tools they're already using to strengthen security, improve collaboration, and build more resilient software from the start.
