코드 시리즈로 보안 인프라를 정복하는 코더 - 신뢰할 수 없는 출처의 구성 요소 사용
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., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Unternehmen da, um den Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Unabhängig davon, ob Sie AppSec-Manager, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind, können wir Ihnen dabei helfen, die Risiken zu reduzieren, die mit unsicherem Code verbunden sind.
Demo-Termin vereinbaren
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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 과제에 대해 알아보십시오.
Klicken Sie auf den folgenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Unternehmen da, um den Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Unabhängig davon, ob Sie AppSec-Manager, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind, können wir Ihnen dabei helfen, die Risiken zu reduzieren, die mit unsicherem Code verbunden sind.
Bericht anzeigenDemo-Termin vereinbaren
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
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 과제에 대해 알아보십시오.
Inhaltsverzeichnis
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Unternehmen da, um den Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit oberste Priorität hat. Unabhängig davon, ob Sie AppSec-Manager, Entwickler, CISO oder in einem anderen Bereich der Sicherheit tätig sind, können wir Ihnen dabei helfen, die Risiken zu reduzieren, die mit unsicherem Code verbunden sind.
Demo-Termin vereinbarenDownloadHilfreiche Ressourcen für den Einstieg
Themen und Inhalte der Sicherheitsschulung
Die branchenweit besten Inhalte werden unter Berücksichtigung der Kundenrollen ständig weiterentwickelt und an die sich ständig verändernde Softwareentwicklungsumgebung angepasst. Es werden Themen angeboten, die alle Bereiche von KI bis hin zu XQuery-Injection abdecken und für verschiedene Rollen geeignet sind, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA-Mitarbeitern. Sehen Sie sich vorab an, was der Inhaltskatalog nach Themen und Rollen zu bieten hat.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Hilfreiche Ressourcen für den Einstieg
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
Cybermon 2025 Bit The Boss ist jetzt das ganze Jahr über bei SCW verfügbar. Stärken Sie die Entwicklung von Sicherheits-KI in großem Maßstab durch den Einsatz fortschrittlicher KI/LLM-Sicherheitslösungen.
Erläuterung des Gesetzes zur Cyber-Resilienz: Bedeutung der Entwicklung von Sicherheitsdesign-Software
Erfahren Sie mehr über die Anforderungen und Anwendungsbereiche des EU-Cyberresilienzgesetzes (CRA) und darüber, wie sich Ingenieurteams durch Design, Praktiken, Schwachstellenvermeidung und die Einrichtung einer Entwicklerumgebung sicher vorbereiten können.
Erfolgsfaktor 1: Definierte und messbare Erfolgskriterien
Enabler 1 bietet eine zehnteilige Reihe von Erfolgsfaktoren, die zeigen, wie sichere Codierung zu Geschäftsergebnissen wie einer schnelleren Risikominderung und Kostensenkung für die Reifung langfristiger Programme beitragen kann.
