セキュリティコードインサイト

점점 더 혼란스러운 이 세상에서 사람들이 믿고 의지할 수 있는 몇 가지 변함이 항상 존재해 왔습니다. 아침에는 해가 뜨고 밤에 다시 질 것이고, 마리오는 언제나 소닉 더 헤지호그보다 더 차갑고, 인젝션 공격은 오픈 웹 애플리케이션 보안 프로젝트 (OWASP) 목록에서 항상 상위권을 차지할 것입니다. 가장 흔한 상위 10위 공격자가 적극적으로 악용하는 위험한 취약성

음, 내일 해가 뜰 거고, 마리오는 여전히 소닉에서 “원 업 (one-up)" 을 하고 있지만, 2021년에 갱신된 악명 높은 OWASP 목록에서 인젝션 어택은 1위 자리를 벗어났습니다.가장 오래된 형태의 공격 중 하나인데 주사 취약점 컴퓨터 네트워킹만큼이나 오래 전부터 존재해 왔습니다.포괄적인 취약점은 기존 공격의 모든 것을 포함하여 광범위한 공격의 원인이 됩니다. SQL 인젝션 객체 그래프 탐색 라이브러리 (OGNL) 에 대해 시작된 익스플로잇에 대해심지어 를 사용하여 서버를 직접 공격하는 것도 포함됩니다. OS 커맨드 인젝션 기법.공격 가능성이 있는 장소의 수는 말할 것도 없고, 공격자가 다양한 인젝션 취약점을 이용할 수 있다는 점 때문에 이 범주는 수년 동안 최고의 자리를 지켰습니다.

하지만 인젝션 킹은 쓰러졌습니다.왕 만세.

인젝션 취약점 문제를 마침내 해결했다는 뜻인가요?기회는 아니야.보안 적 1위라는 지위에는 크게 뒤쳐지지 않았고, OWASP 목록에서 3위까지만 내려갔습니다.인젝션 공격의 지속적인 위험성을 과소평가하는 것은 실수이겠지만, 또 다른 취약점 범주가 이를 능가할 수 있었다는 사실은 의미가 있습니다. 새로운 OWASP 최상위 도그가 실제로 얼마나 널리 퍼져 있고 개발자들이 앞으로 이 문제에 주의를 기울여야 하는지를 보여주기 때문입니다.

하지만 아마도 가장 흥미로운 점은 OWASP Top 10 2021에 대대적인 개편이 반영되어 있다는 점일 것입니다. 안전하지 않은 설계, 소프트웨어 및 데이터 무결성 실패, 커뮤니티 설문조사 결과를 기반으로 한 항목인 서버 측 요청 위조 등이 있습니다.이로 인해 아키텍처 취약성에 대한 관심이 높아지고 있으며 표면적 버그를 넘어 소프트웨어 보안의 벤치마크 대상으로 삼고 있습니다.

깨진 액세스 제어가 왕좌를 차지하다 (추세를 드러낸다)

깨진 액세스 제어는 OWASP 10대 취약점 목록에서 5위를 차지했던 것이 현재 1위까지 치솟았습니다.Injection 취약점이나 안전하지 않은 디자인과 같은 새로운 항목과 마찬가지로, 이 취약점은 광범위한 코딩 결함을 포함하고 있는데, 이 취약점은 집합적으로 여러 측면에서 손상을 허용한다는 점에서 그 인기가 더욱 높아지고 있습니다.이 범주에는 사용자가 의도한 권한을 벗어난 행동을 할 수 있도록 액세스 제어 정책을 위반할 수 있는 모든 인스턴스가 포함됩니다.

OWASP가 취약성 제품군을 최상위 지점으로 끌어올리면서 인용한 깨진 액세스 제어의 예로는 공격자가 URL, 내부 애플리케이션 상태 또는 HTML 페이지의 일부를 수정할 수 있게 하는 경우가 있습니다.또한 사용자가 기본 액세스 키를 변경하여 애플리케이션, 사이트 또는 API가 자신이 다른 사람 (예: 상위 권한을 가진 관리자) 인 것으로 인식하도록 허용할 수도 있습니다.심지어 공격자가 메타데이터를 수정하지 못하도록 제한되지 않아 JSON 웹 토큰, 쿠키 또는 액세스 제어 토큰과 같은 항목을 변경할 수 있는 취약성도 포함되어 있습니다.

공격자는 일단 악용되면 이 취약성 계열의 취약점을 사용하여 다음과 같은 작업을 수행할 수 있습니다. 파일 또는 객체 우회 권한 부여를 통해 데이터를 도용하거나 데이터베이스 삭제와 같은 파괴적인 관리자 수준의 기능을 수행할 수 있습니다.이로 인해 액세스 제어가 중단되는 것은 매우 위험할 뿐만 아니라 점점 더 흔해지고 있습니다.

인증 및 액세스 제어 취약점이 공격자가 악용할 수 있는 가장 빈번한 기반이 되고 있다는 사실은 매우 매력적이지만 놀라운 일은 아닙니다.Verizon의 최신 소식 데이터 침해 조사 보고서 액세스 제어 문제는 거의 모든 산업, 특히 IT 및 의료 분야에서 널리 퍼져 있으며 전체 보안 침해 중 무려 85% 가 인적 요소와 관련된 것으로 나타났습니다.현재 “인적 요소”에는 피싱 공격과 같은 사고가 포함되는데, 이는 엔지니어링상의 문제는 아니지만 침해 중 3% 가 악용 가능한 취약점과 관련된 것이었으며, 보고서에 따르면 보안 구성 오류와 같이 주로 오래된 취약점과 인적 오류로 인한 것이었습니다.

XSS 및 SQL 인젝션과 같은 노후한 보안 버그가 계속해서 개발자의 마음을 사로잡는 가운데, 핵심 보안 설계가 실패하여 위협 행위자에게 매우 유리할 수 있는 아키텍처 취약점에 자리를 내주고 있다는 것이 분명해졌습니다. 특히 특정 애플리케이션 버전의 보안 결함이 공개된 후 패치를 적용하지 않는 경우 더욱 그렇습니다.

문제는 기본을 넘어서는 교육과 기술 개발을 받는 엔지니어가 거의 없으며, 애초에 일반적으로 개발자가 도입한 현지화된 코드 수준의 버그를 넘어서서 지식과 실제 적용을 진정으로 확장하는 엔지니어는 여전히 적다는 것입니다.

로봇이 거의 발견하지 못하는 버그 방지

새로 그룹화된 취약점 취약성 패밀리는 상당히 다양합니다.깨진 액세스 제어의 몇 가지 구체적인 예와 이를 방지하는 방법을 확인할 수 있습니다. 우리의 유튜브 채널 그리고 우리 블로그.

하지만 저는 이 새로운 OWASP Top 10을 기념하는 것이 중요하다고 생각합니다. 스캐너가 반드시 포착할 수 없는 공격 벡터를 포함하는 더 광범위한 공격 벡터를 포함하여 실제로 더 다양합니다.코드 수준의 약점이 발견될 때마다 아무리 자동화된 방패와 무기가 있더라도 대부분의 보안 기술 스택은 더 복잡한 구조적 결함을 알아차리지 못할 것입니다.OWASP Top 10 목록에서 가장 큰 비중을 차지하는 것은 여전히 스캐닝 데이터를 기반으로 작성되지만, 안전하지 않은 설계와 데이터 무결성 실패 등을 다루는 새로운 항목은 로봇이 할 수 없는 것을 달성하기 위해 개발자의 교육 범위를 빠르게 확장해야 한다는 것을 보여줍니다.

간단히 말해서 보안 스캐너는 훌륭한 위협 모델러가 되지는 않지만 보안 기술을 갖춘 개발자 팀은 모범 사례와 비즈니스 요구 사항에 따라 보안 IQ를 높여 AppSec 팀을 헤아릴 수 없을 정도로 도울 수 있습니다.OWASP Top 10은 훌륭한 기준이지만 위협 환경이 너무 빠르게 변화하기 때문에 (내부 개발 목표의 요구는 말할 것도 없고) 보안에 대한 개발자 기술 향상을 위해 더 심층적이고 구체적인 계획을 세워야 한다는 점을 염두에 두고 이를 훌륭한 보안 프로그램에 반영해야 합니다.그렇게 하지 않으면 필연적으로 조기 치료 기회를 놓치게 되며 예방적이고 인간 주도의 사이버 보안에 대한 성공적인 총체적 접근이 저해될 수밖에 없습니다.

‍

우리는 2021년 OWASP 톱 10을 준비했습니다. 이는 시작에 불과합니다!개발자를 지금 바로 시작하세요 고급 보안 기술 경로 오늘.

이 기사의 한 버전이 에 게재되었습니다. 다크 리딩.여기에서 업데이트 및 신디케이트되었습니다.

‍

문화를 뒤흔드는 최신 AI 도구에 대한 초창기부터 개발자와 코딩에 관심이 있는 사람들 모두 버튼 하나만 누르면 코드를 생성하는 데 이 도구를 사용해 왔습니다.보안 전문가들은 대부분의 경우 제작 중인 코드가 다음과 같다는 점을 재빨리 지적했습니다. 품질이 좋지 않고 취약합니다.보안에 대한 인식이 거의 없는 사용자의 손에 넘어가면 안전하지 않은 앱과 웹 개발이 쏟아져 나와 순진한 소비자에게 피해를 줄 수 있습니다.

그리고 보안 지식을 충분히 가지고 있어서 악의적인 용도로 사용하는 사람들도 있습니다.모든 놀라운 AI 위업에도 불구하고 동일한 기술이 사용된다는 점에서 역효과가 있는 것 같습니다. 악의적인 목적.피싱, 딥 페이크 스캠 동영상, 멀웨어 제작, 일반적인 스크립트로 엉망인 속임수... 이러한 파괴적인 활동은 진입 장벽이 낮아 훨씬 빠르게 달성할 수 있습니다.

이 도구를 혁신적이라고 선전하는 클릭베이트가 많거나 적어도 “평균적인” 인간의 기술과 비교할 때 정상에 오를 수 있다고 선전하는 클릭베이트가 많이 있습니다.LLM 스타일의 AI 기술이 소프트웨어 개발뿐만 아니라 업무의 여러 측면에 접근하는 방식을 바꾸는 것은 불가피해 보이지만, 우리는 한 발 물러서서 헤드라인 너머의 위험을 고려해야 합니다.

코딩 동반자로서 이 제품의 결점은 아마도 가장 '인간적인' 특성일 것입니다.

잘못된 코딩 패턴이 주요 솔루션을 지배합니다.

ChatGPT가 수십 년간 쌓아온 기존 코드와 지식 베이스를 기반으로 학습했기 때문에, ChatGPT가 그 모든 경이로움과 미스터리에도 불구하고 사람들이 코드를 탐색할 때 직면하는 일반적인 함정에 시달린다는 것은 놀라운 일이 아닙니다.잘못된 코딩 패턴은 필수이며, 올바른 질문을 하고 적절한 즉각적인 엔지니어링을 제공하여 보안 코딩 예제를 생성하려면 여전히 보안을 잘 아는 드라이버가 필요합니다.

그럼에도 불구하고 제공된 코드 스니펫이 보안 관점에서 정확하고 기능적이라는 보장은 없습니다. 이 기술은 환각 현상을 일으키기 쉽습니다. 존재하지 않는 라이브러리 구성 마이크 셰마가 발견한 특정 JSON 작업을 수행하라는 요청을 받았을 때이로 인해 위협 행위자들의 '환각 스쿼팅'이 발생할 수 있습니다. 위협 행위자는 ChatGPT에서 자신있게 추천한 조작된 라이브러리로 위장한 멀웨어를 너무 기꺼이 만들어낼 수 있습니다.

궁극적으로 우리는 일반적으로 개발자들이 보안에 대해 충분히 인식할 것으로 기대하지 않았으며, 업계로서 보안 코드를 기본 상태로 작성하도록 적절하게 준비하지도 못했다는 현실을 직시해야 합니다.이는 ChatGPT에 입력되는 어마어마한 양의 학습 데이터에서도 분명하게 드러날 것이며, 적어도 초기에는 그 결과에서도 이와 비슷한 부실한 보안 결과를 기대할 수 있습니다.개발자는 보안 버그를 식별하여 직접 수정하거나 더 강력한 결과를 위해 더 나은 프롬프트를 설계할 수 있어야 합니다.

첫 번째 대규모 사용자 연구 스탠포드 대학의 연구원들이 수행한 다양한 보안 관련 기능을 해결하기 위해 사용자가 AI 코딩 어시스턴트와 상호 작용하는 방식을 조사한 결과 이 개념을 뒷받침하며, 한 가지 관찰 결과는 다음과 같습니다.

”AI 어시스턴트에 액세스할 수 있는 참가자는 대부분의 프로그래밍 작업에서 보안 취약점을 도입할 가능성이 더 높았지만, 대조군에 속한 참가자에 비해 안전하지 않은 답변을 안전하다고 평가할 가능성도 더 높다는 것을 관찰했습니다..”

이는 AI 코딩 도구의 출력에 대한 기본 신뢰 수준을 말해주는데, 이는 항상 본질적으로 안전하지 않지만 실제로는 안전하지 않은 코드를 생성한다는 의미입니다.

이 위협과 미래에 스며들 피할 수 없는 AI 기반 위협 사이에서 개발자들은 이제 그 어느 때보다 보안 기술을 연마하고 출처를 불문하고 코드 품질에 대한 기준을 높여야 합니다.

데이터 유출 재해로 가는 길은 좋은 의도로 포장되어 있습니다

AI 코딩 컴패니언이 인기가 있다는 것은 놀라운 일이 아닙니다. 특히 개발자들은 점점 더 많은 책임과 촉박한 마감일, 회사의 혁신에 대한 야망이 어깨에 달려 있는 상황에서 더욱 그렇습니다.그러나 아무리 좋은 의도를 가지고 있더라도 코딩에 AI를 사용할 때 실행 가능한 보안 인식이 부족하면 필연적으로 심각한 보안 문제가 발생할 수밖에 없습니다.AI/ML 도구를 사용하는 모든 개발자는 더 많은 코드를 생성하게 되며, 보안 위험 수준은 기술 수준에 따라 달라집니다.조직은 교육을 받지 않은 사람이 코드를 더 빠르게 생성할 수 있지만 기술 보안 부채의 속도도 증가할 것이라는 점을 잘 알고 있어야 합니다.

ChatGPT를 사용한 사전 테스트 (2023년 4월) 에서도 이 경우 치명적인 결과를 초래할 수 있는 아주 기본적인 실수가 발생할 수 있다는 사실이 밝혀졌습니다.MySQL 데이터베이스를 사용하여 PHP로 로그인 루틴을 구축하도록 요청했을 때 함수 코드가 빠르게 생성되었습니다.하지만 기본적으로 암호를 데이터베이스에 일반 텍스트로 저장하고, 데이터베이스 연결 자격 증명을 코드에 저장하고, SQL 인젝션을 초래할 수 있는 코딩 패턴을 사용했습니다 (하지만 입력 매개 변수에 대해 일정 수준의 필터링을 수행하고 데이터베이스 오류를 찾아냈지만).어떤 척도에서든 모든 신인 오류는 다음과 같습니다.
‍

‍
추가 프롬프트를 통해 실수를 수정했지만 과정을 수정하려면 상당한 보안 지식이 필요합니다.이러한 도구를 확인하지 않고 널리 사용하는 것은 후배 개발자를 프로젝트에 참여시키는 것보다 낫지 않습니다. 만약 이 코드가 민감한 인프라를 구축하거나 개인 데이터를 처리하는 것이라면 시한폭탄이 터지는 셈입니다.

물론 주니어 개발자들이 시간이 지남에 따라 기술이 향상되는 것처럼 AI/ML 기능도 향상될 것으로 예상됩니다.지금으로부터 1년 후에는 그렇게 명백하고 단순한 보안 실수를 범하지 않을 수도 있습니다.하지만 이를 통해 여전히 발생할 위험이 있는 더 심각하고, 숨겨져 있고, 사소하지 않은 보안 오류를 찾아내는 데 필요한 보안 기술이 크게 향상될 것입니다.

우리는 여전히 보안 취약점을 찾아 수정할 준비가 제대로 되어 있지 않으며 AI는 격차를 넓힙니다.

이 시점에서 수년 동안 '좌익의 전환'에 대한 논의가 많았지만, 대부분의 조직에서 개발 집단 사이에 실질적인 보안 지식이 크게 부족하다는 사실은 변함이 없습니다. 따라서 우리는 조직의 발전에 도움이 되는 적절한 도구와 교육을 제공하기 위해 더 많은 노력을 기울여야 합니다.

현재로서는 익숙한 보안 버그에 대한 준비가 되어 있지 않습니다. 들불처럼 도래할 완전히 새로운 공격 경로를 나타내는 프롬프트 인젝션 및 환각 스쿼팅과 같은 새로운 AI 관련 문제는 말할 것도 없습니다.AI 코딩 도구는 개발자의 코딩 무기의 미래를 대표하지만, 이러한 생산성 무기를 안전하게 사용할 수 있는 교육은 지금부터 시작해야 합니다.

‍

인생에서 일반적으로 의사 소통은 대단한 일입니다.이해하고, 새로운 것을 배우거나, 관계를 구축하는 데 이보다 더 빠른 방법은 없습니다.소프트웨어 분야에서 API는 애플리케이션이 서로 통신하여 기능과 사용성을 높일 수 있도록 하는 의사소통의 역할을 합니다.이러한 연결성은 최종 사용자가 좋아하는 풍부한 경험을 제공하며, 일상 생활에서 소프트웨어에서 기대하는 바가 점점 더 많아지고 있습니다.

하지만 실생활과 마찬가지로 말을 너무 많이 하면 큰 문제가 됩니다.Experian은 최근에 이 사실을 어렵게 알게 되었는데, 타사 파트너가 자사 API 중 하나를 사용하면서 잠재적으로 유출되었습니다 거의 모든 미국 시민들의 신용점수는

이 문제는 빠르게 패치되었지만 이 취약점이 실제로 차단되었는지에 대한 의문이 남아 있습니다.한 공급업체가 영향을 받았다면 다른 공급업체도 영향을 받았을 가능성이 높으며, 이 문제가 발생할 가능성도 있습니다. 시스템 버그안전하지 않은 API를 사용하는 모든 사람에게 영향을 미칩니다.

API 보안은 대부분의 보안 전문가들이 머릿속에 떠올리지 않는 문제이며, 이에 맞서 싸우기 위한 지식을 갖추어야 하는 문제이기도 합니다.

스워시버클 괴짜라면 누구나 잘못된 API 인증을 우회할 수 있습니다.

많은 데이터 유출, 침해 및 보안 사고의 특징 중 하나는 이를 달성하기 위해 지도자가 거의 필요하지 않다는 것입니다.SolarWinds에서 보았던 것처럼 복잡하고 교활하며 피해를 주는 공격에는 천재적인 사이버 범죄자들로 구성된 팀이 필요하며, 이는 규칙이 아니라 예외입니다.

API가 취약한 인증으로 구축되면 악용되기 쉽습니다.Experian의 API 버그를 발견한 보안 연구원인 빌 데미르카피는 별다른 인증 없이도 액세스할 수 있다고 판단했습니다.생년월일 필드에 00/00/0000을 입력하면 이름 및 관련 우편 주소와 같이 공개적으로 이용 가능한 정보만 사용하여 개인의 신용 점수를 확인할 수 있었습니다.아직 보고된 바는 없지만, 이러한 기록이 스크랩되어 신용 관련 데이터 덤프로 (따라서 가치가 있는) 문맥화될 가능성은 분명히 존재합니다.

사용 사례가 아무리 작더라도 깔끔하고 기능적인 인증 프로세스를 마련해야 합니다. 보안이 제대로 이루어지지 않아 여러 시스템에 대한 액세스를 허용할 수 있는 Chatterbox API는 문제가 될 수 있습니다.

깨진 인증은 두 번째로 중요한 요소입니다. OWASP 탑 10 API 취약점 목록. 여기에서 더 읽어보세요 이 버그를 피할 수 있는 방법에 대해 알아보고 두뇌에 영양을 공급한 후 당사 플랫폼에서 기술을 테스트해 보세요.

부실한 API 보안 통제는 문화적 변화를 요구하는 만연한 문제입니다.

Experian과 같은 조직만을 비난하는 것은 공평하지 않지만, 이러한 특정 API 노출에서 나타난 미묘한 차이와 보안 통제의 부재는 IT 시스템 및 엔드포인트의 일부로 API를 탐색하고 있는 많은 기업에게 좋은 징조가 아닙니다.

일반적으로 API 취약점을 찾아 해결하는 것뿐만 아니라 우리가 보호해야 할 공격 영역의 일부로서 이를 이해하는 데에도 많은 작업이 필요합니다.API와 그 구축 방식에 대한 가시성은 큰 관심사이며 보안 모범 사례의 일환으로 요구되어야 할 사항입니다.가장 엄격한 보안 조치를 취하고 있는 조직도 회사 보안 통제 범위를 벗어난 채 게시되고 작동하는 API에 의해 무력화될 수 있습니다.API의 출처가 어디인지, 누가 최종적으로 API를 유지 관리하는지 (타사 공급업체인지) 묻는 것이 그 어느 때보다 중요합니다.보안에 대해 얼마나 엄격한가요?그리고 어떤 정보를 액세스하고 있는지

인젝션 취약성은 모든 CISO의 골목으로 남아 있습니다.

API 보안은 보안 프로그램에 포함시키기에는 상당히 새로운 모듈처럼 보일 수 있지만, 우리가 평범한 구식 웹 소프트웨어에서 보던 (아주) 오래된 트릭에 의해 악용될 수 있습니다.

A 최근 공개된 액셀리온에 대한 공격 위협 행위자가 연쇄적인 SQL 인젝션 및 OS 명령 실행 공격을 통해 API를 조작하여 사회보장번호를 비롯한 중요한 데이터를 대량으로 추출할 수 있었다는 사실이 밝혀졌습니다.그들은 공격자들이 하이스트를 수행하려면 Accellion의 FTA 소프트웨어에 대한 광범위한 지식이 있어야 한다고 판단했는데, 이는 상당한 리버스 엔지니어링을 통해 가능했을 것입니다.

2020년 12월과 2021년 1월에 걸쳐 침해 사고가 발생했기 때문에 도둑들이 피해를 입힐 수 있는 시간은 충분했습니다.2021년 2월에 추가로 발견된 결과 저장된 XSS 취약점이 발견되었으며, 포렌식 분석을 통해 사용자 입력을 부적절하게 삭제한 API 엔드포인트 하나만으로도 호출 시 인수를 주입할 수 있는 것으로 나타났습니다. admin.pl 스크립트.

많은 유명 교육 기관을 포함하여 3,000명 이상의 고객을 보유한 이 보안 침해는 광범위할 수 있습니다.안타깝게도 이러한 악용은 일반적인 취약점을 활용하여 가능했는데, 이러한 취약점 중 상당수는 보안을 잘 아는 개발자가 코드 수준에서 사전 프로덕션 단계에서 해결할 수 있었을 것입니다.몇 번이고 반복해서 보게 되겠지만, 작은 창을 열어 놓아도 큰 문제가 발생할 수 있습니다.그리고 인간이 주도하는 사이버 방어 문화도 인간적인 문제를 해결하기 위한 전략의 일부가 되어야 합니다.

지금 API 보안 기술을 테스트하고 싶으신가요? 자바 스프링 API, 코틀린 스프링 API, C# (.NET) 웹 API 그리고 더 있나요?학습 플랫폼에서 API 챌린지를 시도해 보세요 (드롭다운을 통해 모든 언어:프레임워크를 확인하세요).
‍

‍

더 생산적인 Java 개발자가 되세요

전 세계적으로 9백만 명의 개발자*를 보유한 Java (Oracle Corporation) 는 세계에서 가장 인기 있는 프로그래밍 언어 중 하나입니다.많은 응용 프로그램 프레임워크가 Java를 기반으로 구축되었습니다. Java Runtime Environment (JRE) 는 모든 Java 프로그램이 실행되는 환경인 Java Runtime Environment (JRE) 를 지원하는 다양한 장치에서 프로그램을 실행할 수 있는 매우 다양한 언어이기 때문입니다.개발자 주도 커뮤니티는 매우 활발하며 초보 프로그래머가 이용할 수 있는 심층적인 지원으로 인기가 계속 높아지고 있습니다.

Java는 오랫동안 사용되어 왔기 때문에 커뮤니티에서는 표준, 도구, 코딩 패턴을 개발하고 개발자들이 반복해서 직면하는 일반적인 실수를 완화하는 데 수년을 보냈습니다.커뮤니티가 주도하는 이러한 모든 이니셔티브에는 한 가지 공통된 목표가 있습니다. 바로 개발자가 Java로 애플리케이션을 개발할 때 생산성을 최대한 높일 수 있도록 돕는 것입니다.그러나 응용 프로그램 코드에 모범 사례나 패턴을 적용할 때 책임은 개발자에게 있습니다.모범 사례를 적용하는 방식이 매우 다양하기 때문에 커뮤니티 내에서 의견이 많이 다를 경우 코딩 관행에 대한 표준적인 접근 방식을 취하기가 어렵습니다.개발자들은 온라인 커뮤니티에서 도움을 구하는데, 때로는 의도치 않게 코딩 문제에 대한 안전하지 못한 해결책을 제시하기도 합니다.

개발자가 일반적인 Java 코딩 문제에 대한 보안 솔루션을 구현할 수 있도록 돕기 위해 Sensei를 만들었습니다. Sensei는 전문적인 환경에서 사용자 또는 조직이 정의한 레시피 (또는 규칙) 에 따라 잘못된 코딩 패턴을 수정하는 IntelliJ 플러그인입니다.Sensei를 사용하면 개발자가 클릭 한 번으로 일반적인 Java 실수 (문제) 를 식별하고 수정할 수 있습니다.

Sensei가 일반적인 Java 코딩 실수를 해결하여 개발자 생산성을 높이는 방법을 알아보려면 계속 읽어보세요.

개발자를 좌절시키는 반복되는 실수

이러한 일반적인 실수의 한 가지 예는 래퍼 값의 잘못된 동등성 검사입니다.예상치 못한 결과를 방지하려면 참조 비교 연산자 (= =) 대신 equals 메서드를 사용하여 박스형 프리미티브의 값을 비교해야 합니다.

예를 들어, -128~127 범위의 정수 값에 대해 참조 비교 연산자를 사용하면 (일반적으로) equals 메서드와 동일하게 동작합니다.하지만 이 범위를 벗어나는 값과 동일한 비교를 수행하면 결과가 달라집니다.이는 Java가 앞서 언급한 정수 값 범위에 대해 일정한 풀을 유지하기 때문입니다.equals 메서드를 사용하면 항상 예상 결과를 얻을 수 있으므로 비교하기에 적합한 방법입니다.

이 예제에서는 연산자 (==) 를 잘못 사용하여 동등성을 검사하고 있습니다.

그 결과 다음과 같은 결과가 출력됩니다.

참된

거짓

거짓

참된

비교하는 올바른 방법은 equals 방법을 사용하는 것입니다.

그러면 출력은 다음과 같습니다.

참된

거짓

참된

거짓

잘 알려진 이 베스트 프랙티스는 꽤 오랫동안 사용되어 왔지만, 가장 적절하지 않은 시기에 제대로 작동하지 않는 레거시 코드에서 제대로 구현되지 않는 경우가 많습니다.그래서 로컬에서 이러한 바람직하지 않은 코딩 패턴을 식별하고 Sensei를 사용하여 클릭 한 번으로 수정 사항을 적용할 수 있는 레시피 (또는 규칙) 를 만들었습니다.

Sensei는 입력 시 원하지 않는 코드를 스캔하고 수정할 수 있는 고도로 사용자 정의 가능한 IDE 플러그인입니다. 수백 개의 다운로드 가능한 코드 변환 및 마이그레이션 레시피 (규칙) 뿐만 아니라 직접 작성할 수 있는 기능이 내장되어 있습니다.개발자는 Sensei를 사용하여 코드를 입력할 때 잘못된 코드 패턴을 수정하여 양질의 코드를 더 빠르게 제공하고 궁극적으로 팀과 프로젝트 전반에서 일관되고 표준적인 방식으로 코드를 작성할 수 있습니다.

Sensei가 이러한 일반적인 Java 문제를 해결하는 방법

Sensei에서는 자신만의 레시피를 만들 수 있으므로 위에서 언급한 실수를 수정하기 위해 레시피를 만들었습니다.

이 예제에서는 박스형 프리미티브 타입에서 비교 연산자 (==) 를 사용하는 위치를 찾으려고 합니다.

센세이 레시피는 다음과 같습니다 (YAML).

위의 내용은 입력할 때 반복되는 잘못된 패턴 또는 전체 파일, 구성된 범위, 전체 코드베이스를 검색할 수 있습니다.패턴이 발견되면 자연스러운 다음 단계는 온라인에서 검색하지 않고도 즉시 수정할 수 있는 것입니다.Sensei를 사용하면 지정된 대로 코드를 추가/편집/삭제할 수 있는 수정 프로그램을 만들 수 있습니다.적합하다고 판단되는 수정 사항을 여러 개 제공하여 개발자가 적합하다고 판단되는 가장 적절한 수정 사항을 선택할 수도 있습니다.

이 예제에서는 연산자 (==) 대신 equals 메서드를 사용하여 비교를 다시 작성하려고 합니다.

사용 가능한 수정 사항은 다음과 같이 설명됩니다.

작동 방식:

간편한 방법으로 표준 코딩 지침 구현

Java Gotchas Cookbook에는 일반적인 실수를 피하고 코드를 깔끔하고 안전하게 유지하는 데 도움이 되는 22가지 레시피가 있습니다.객체 동등성, 예외 처리, 정규 표현식 및 컬렉션과 같은 다양한 Java 언어 기능 및 API의 부정확하거나 안전하지 않은 사용을 감지합니다.Sensei와 이 쿡북을 사용하면 처음부터 더 나은 코드를 작성할 수 있을 뿐만 아니라 고유한 팀, 프로젝트 또는 조직에 맞게 자신만의 레시피를 만들 수도 있습니다.

이는 Sensei를 사용하여 프로젝트를 표준화할 수 있는 다양한 방법 중 하나에 불과합니다.풀 리퀘스트나 직접 코딩할 때 자주 접하는 안티패턴 또는 특정 수동 코드 변환이 있으면 언제든지 찾아볼 수 있습니다.개발자들이 자주 놓치는 코딩 가이드라인이 있다면 가이드라인을 레시피로 변환하여 개발자가 승인된 코드 변환을 자신 있게 적용할 수 있습니다.

지금 Sensei를 설치하고 생산적인 개발 경험을 위해 Java Gotchas Cookbook을 활성화하세요. https://sensei.securecodewarrior.com/cookbooks/scw:java

*2021, 개발자 국가 현황, https://www.developernation.net/developer-reports/de20

‍

부채에 대해 이야기해 봅시다.

사이버 범죄가 글로벌 경제가 직면한 주요 문제가 되었다는 사실은 이제 누구나 알고 있습니다.2022년 현재 미국의 데이터 침해로 인한 평균 비용은 944만 달러로 전년도 905만 달러에서 증가했습니다.안전하지 않은 코드로 인한 비용과 누적된 기술적 부채를 무시하지 않는 것이 중요합니다.2022년에 따르면 정보 및 소프트웨어 품질 컨소시엄: 소프트웨어 품질 저하로 인한 비용 보고서에 따르면 미국의 소프트웨어 품질 저하로 인한 비용은 2조 4,100억 달러로 증가했으며 누적된 소프트웨어 기술 부채는 1조 5,200억 달러로 증가한 것으로 추정됩니다.

안전하지 않은 코드를 해결하는 데 드는 급증하는 비용과 그에 따른 기술적 부채는 기존 코드 베이스를 변경하는 데 있어 가장 큰 장애물이 되어 악용 및 외부 위협에 취약하게 되었습니다.소프트웨어 보안 상태가 실존적 위기에 직면해 있습니다. 누적된 기술적 부채를 해소할 뿐만 아니라 보안 태세를 개선해야 한다는 것을 알고 있지만 그 장벽은 엄청납니다.

• 미국에는 약 30만 개의 소프트웨어 개발자 및 IT 관련 일자리가 채워지지 않고 있으며 15% 의 성장률이 예상됩니다.
• 2025년까지 IT 예산의 40% 가 단순히 기술 관련 부채를 유지하는 데 사용될 것으로 예상됩니다.
• 개발자의 주당 평균 근무 시간의 1/3이 기술 부채 해결에 사용됩니다.

빠른 수정은 위험하며 장기적으로 비용이 더 많이 듭니다.

기술 부채란 무엇이며 왜 그렇게 중요한가요?의사 결정권자가 소프트웨어 개발 문제에 대한 보다 포괄적이고 장기적인 해결책 대신 단기적인 해결책을 찾으면 기술 부채가 누적됩니다.여기에는 조직이 나중에 지불해야 하는 상당한 숨겨진 비용이 뒤따릅니다.신용카드의 최대 한도액과 마찬가지로 기술 부채에도 크게 두 가지 요소가 있습니다.

• 주요한 - 소프트웨어를 원하는 수준의 유지 관리 및 보안에 도달하도록 리팩토링하거나 수정하는 데 드는 총 비용을 말합니다.
• 관심 - 개발자가 새로운 기능이 아닌 기술적 문제만을 해결하기 위해 이러한 변경을 위해 소비하는 추가 노력.정확하지 않은 코드에 시간을 할애할 때마다 부채에 이자가 추가됩니다.

새로운 기능, 버그 수정 및 유지 관리 비용이 프로젝트 예산을 초과하여 소프트웨어 응용 프로그램의 가치를 크게 떨어뜨리면 결국 “기술적 파산” 상태에 도달할 수 있습니다.

그러나 삶에서와 마찬가지로 일부 부채 축적은 정상이며 대부분의 경우 어느 정도 예상됩니다.

이상적으로는 모든 소프트웨어 개발자가 코드를 발송하기 전에 버그를 최대한 줄이는 것이 좋습니다.하지만 조직에서는 경쟁력을 갖추기 위해 최소한의 비용으로 기능이나 제품을 신속하게 고객에게 제공하고자 하는 등 어려운 절충점에 직면해 있습니다.결과적으로 개발자의 KPI는 제공 속도와 초기 구축 비용을 기반으로 하기 때문에 애플리케이션의 품질이 떨어집니다.그림에서 빠진 것은 누적된 결함과 잠재적 취약점이 코드에 내장되어 있다는 것입니다.이로 인해 버그가 발생하거나 보안 취약점이 무성할 수 있으며, 심하면 악의적인 공격자의 악용에 노출될 수도 있습니다.

하지만 수수께끼가 있습니다. 막대한 기술적 부채를 축적하지 않고 제품을 신속하게 배송할 수 있는 다른 방법이 있을까요?

결함과 취약점을 발견하고 해결하는 데 드는 비용은 소프트웨어 개발 라이프사이클에서 단일 비용 중 가장 큰 비용입니다.개발 라이프사이클 초기에 문제가 발견될수록 전체 딜리버리의 비용 효율성이 높아집니다.

기술 부채는 보안 부채로 발전할 수 있습니다

많은 개발자들은 이미 검증된 솔루션을 사용하여 빠르고 이상적으로 작업할 수 있도록 오픈 소스 코드를 사용하여 이러한 장단점을 피하려고 합니다.하지만 오픈소스 소프트웨어에 크게 의존하고 있습니다. 종종 자체 위험을 초래합니다.:

• 오픈 소스 구성 요소 중 82% 가 오래된 것으로 확인되었습니다 (예: 패치가 적용되지 않았거나 제대로 지원되지 않음)
• 코드베이스의 75% 가 취약점을 포함하고 있으며 (2018년의 60% 에서 증가), 49% 에는 고위험 취약성이 포함되어 있습니다.
• 코드베이스당 평균 82개의 취약점이 식별되었습니다.

이로 인해 기술 부채의 일부인 보안 부채가 급증합니다.보안 부채는 소프트웨어 애플리케이션에 누적되는 취약점으로 인해 데이터 및 시스템을 공격으로부터 보호하기가 더 어려워지거나 심지어 불가능하게 만드는 현상입니다.

가장 악명 높은 사례 중 하나는 신용 보고 대기업인 Equifax입니다. 2017년에 위반되었습니다 널리 사용되는 오픈 소스 웹 애플리케이션 프레임워크인 Apache Struts의 알려진 취약점을 패치하는 데 실패했기 때문입니다.이 패치는 출시된 지 몇 개월이 지났지만 이번 침해로 인해 1억 4,700만 명이 넘는 사람들의 중요한 개인 데이터가 손상되었습니다.

따라서 많은 애플리케이션이 기술적 부채뿐만 아니라 애플리케이션 자체의 보안 약점 및 취약성의 밀도로 인해 임계치에 도달했기 때문에 보안 코딩 관행에 더 많은 관심을 기울여야 합니다.

이로 인해 유형적이든 무형적이든 막대한 손실이 발생할 수 있습니다.

평판 손상:고객의 신뢰 상실은 향후 매우 부정적인 영향을 미칠 수 있습니다.여기에는 브랜드 손상, 판매 손실, 침해로 인한 비용이 많이 드는 법적 문제 등이 포함될 수 있습니다.

규제 및 규정 준수에 미치는 영향:보안 침해로 인해 회사가 기한 및/또는 계약상 의무를 놓칠 수 있는 경우SLA를 준수하지 못하면 회사는 규제 기관과 문제를 일으켜 상당한 벌금이 부과될 수 있습니다.

개선 비용: 장애 또는 운영 중단이 발생한 후에는 생산성 손실을 만회하기 위해 추가 작업이 필요한 경우가 많습니다.

SDLC의 기술 및 보안 부채 방지

많은 조직에서 이미 더 강력한 보안 태세를 구축하기 위해 예산을 변경하고 있습니다.지난 해, 구글은 5년간 100억 달러를 약속했습니다. 사이버 보안 강화 프로그램에 자금을 지원합니다.바이든 행정부도 요청했습니다. 2022년 임의 예산 21억 달러 사이버 보안 및 인프라 보안국 (CISA) 을 위해

개발자의 전문적 성장과 지식을 강화하는 데 도움이 되는 더 많은 리소스와 교육을 제공하는 것이 프로덕션에 출시되는 모든 코드에 대한 품질 표준을 수립하는 첫 번째 단계가 될 수 있습니다.

취약점이나 결함을 발견하고 해결하는 데 드는 비용은 소프트웨어 개발 주기가 늦어질수록 기하급수적으로 증가합니다.지금까지 살펴본 바와 같이 조직은 기술 및 보안 문제를 해결하는 데 너무 많은 시간을 할애하고 있기 때문에 혁신을 포기하고 새로운 기능이나 제품에 시간을 투자함으로써 스스로 손실을 초래하고 있습니다.

2022년에는 개발자 팀 대다수가 DevOps 또는 DevSecOps를 선택한 방법론이라고 말했는데, 그 이유는 놀라운 일이 아닙니다.DevSecOps는 소프트웨어 개발 라이프사이클의 모든 단계에서 보안을 통합하여 더 우수하고 안전한 애플리케이션을 제공합니다.보안 및 개발 팀은 사일로 속에서 계속 작업하며 긴장을 겪고 있지만, 비즈니스의 성공을 위해서는 이러한 변화가 필요하다는 것은 분명합니다.DevOps는 조직이 장벽을 허물고 문화를 재편하려는 방식의 일부입니다.DevSecOps의 기본 목표는 소프트웨어 개발 라이프사이클 초기부터 AppSec/ Security와 개발자 간의 협업을 강화하는 것입니다.

기술적 부채 및 보안 문제를 해결하기 위한 새로운 사고 방식을 구현하는 것이 기념비적인 업적일 필요는 없습니다.조직의 개발자 커뮤니티의 보안 인식과 기술을 향상시키려면 교육을 통해 사전 예방적 사고방식을 확립하는 것이 중요합니다.개발자를 위한 강력한 보안 코딩 교육을 통해 지속적이고, 대화형이며, 관련성이 높고, 상황에 맞는 학습이 필수적입니다.진정한 개발자 주도의 보안 문화를 조성하기 위해 무엇이 필요한지 진정으로 총체적인 접근 방식을 취해야 합니다.개발자 팀을 관리하고 구성하는 일반적인 방식에서 초점을 바꿔야 할 수도 있습니다.

문화를 바꾸는 것은 쉬운 일이 아니지만 Secure Code Warrior는 보안 챔피언을 식별하고 개발자와 조직이 오늘날의 끊임없이 변화하는 보안 문제를 해결하는 데 필요한 적절한 기술을 갖추도록 도와줍니다.

매력적이고 확장 가능한 보안 코드 프로그램을 출시하는 것은 보안에 대한 과거의 사후 대응 방식이 아닌 장기적인 예방적 접근 방식을 취하기 때문에 가치 있는 투자입니다.이는 궁극적으로 침해로 인한 비용이 많이 드는 위험을 완화하고, 개발자에게 취약점을 신속하게 찾아 해결하는 방법을 교육하며, 보다 민첩하게 제품 개발에 집중하고 시장 출시 시간을 단축하는 데 도움이 됩니다.

자연 서식지에 사는 개발자는 촉박한 마감일에 멋진 기능을 코딩하는 등 집중도가 높은 상태를 자주 볼 수 있습니다.기능 구축은 우리가 이 일에서 가장 좋아하는 부분인 경우가 많은데, 사실 기능 구축은 소프트웨어 개발 라이프 사이클 (SDLC) 의 근본적인 결과물입니다.

그러나 앞서 논의한 바와 같이 많은 사람들이 여전히 보안 모범 사례보다 기능을 우선시하고 있습니다.결국 대부분의 조직에서는 업무가 다른 사람의 업무로 설정되어 있고 우리를 위한 적절한 보안 교육도 제한되어 있습니다.침투 테스트 및 정적 분석 스캐닝 도구 (SAST라고도 함) 는 보안 위험을 완화하기 위한 전체 프로세스의 일부에 불과합니다. 물론 핫픽스를 위해 코드가 우리에게 돌아오기 전까지는 우리가 하는 작업과는 별개로 작동합니다.

바로 그 순간 많은 개발자들이 이렇게 생각합니다.”펜테스터들이 나를 싫어하니?”

이러한 상호 작용은 종종 팀, 문화를 정의합니다.걱정되는 점은 커뮤니케이션과 이해, 전반적인 협업의 부재로 인해 적어도 개발자 측에서는 긴장감이 생겼다는 것입니다.생각해 보세요. 멋진 조각상을 만드는 데 몇 백 시간을 보냈는데, 어떤 사람이 망치를 들고 와서 그 기초가 엉망이라는 말을 듣고 조각을 부수기 시작한다고 상상해 보세요.이것이 바로 테스터와 개발자 사이의 인식된 역학 관계입니다. 개발자의 경우 프로세스를 진행하지 않은 외부인이 소프트웨어 애호가를 학살하고 대신 워크로드를 늘리고 배송 코드의 만족도를 지연시켰습니다.

오래 전에 보안 분야로 옮겨 왔기 때문에 이야기의 양면을 모두 볼 수 있습니다.그리고 아니요, 펜테스터는 그렇지 않습니다. 미움 개발자.펜테스터는 아마도 과로하고 많은 압박을 받고 있을 것입니다.따라서 코드 수준에서 쉽게 고칠 수 있는 일반적인 보안 버그가 끊이지 않고 쏟아져 나오더라도 심각한 문제를 해결하느라 시간, 리소스 및 헤드스페이스를 소모하게 됩니다.

저는 항상 펜테스터를 일종의 부모 같은 존재로 여겼어요.그들은 당신이 잘하길 바라는데, 그렇지 않을 때는... 화가 난 게 아니라 실망할 뿐이죠.

이제 (약간 불공평한) 이미지를 머릿속에 담았으니 좀 더 깊이 탐구해 보겠습니다.개발자들 사이에 이런 세계관이 생긴 이유는 무엇일까요?

“당연히 방어적인 태도로 변해가고 있어요. 그들이 제 일을 어떻게 해야 하는지 알려주고 있으니까요!”

자신이 나쁜 일을 했거나 누군가가 자신의 일을 좋아하지 않는 것처럼 느끼는 것을 좋아하는 사람은 아무도 없습니다.안타깝게도 개발자 입장에서는 정적 분석과 Pentest 결과가 돌아오면 성적표처럼 느껴질 수 있습니다.낮은 점수를 받았지만 결국에는 그들의 상사는 소프트웨어에 취약한 요소가 있었는지 여부가 아니라 구축한 기능과 제공 시간을 기준으로 평가합니다.

불쌍한 펜테스터에게는 “메신저를 쏘지 말라”는 경우입니다.개인적인 일은 아니에요. 그들은 버그를 찾아내는 임무를 맡았는데, 버그를 찾아냈죠.물론 개인 대 개인 차원에서는 일부 펜테스터가 다른 사람들보다 심술궂을 수도 있지만 개발팀을 십자가에 못 박으려는 것은 아닙니다 (또는 그렇게 해서는 안 됩니다).두 팀이 보안 모범 사례를 구성하는 요소에 대해 동일한 이해를 가지고 있다면 훨씬 더 쉬울 것입니다.개발자가 완벽할 것으로 기대되지는 않습니다. 현실적으로 테스트 팀은 취약한 코드가 유출되지 않도록 보호하기 위해 존재합니다.

“이 모든 사소한 문제를 해결하라고 하던데, 더 높은 우선 순위가 있다는 걸 모르나요?그리고 애들이 그렇게 신경을 쓰는데 왜 제가 고칠 수 있게 도와주지 않는 거죠?”

사실입니다. 개발자의 최우선 과제는 항상 기능 구축이며, 빠르게 디지털화되는 이 미친 세상에서는 빠른 속도로 완료되어야 합니다.보안과 보안 코딩에 개인적인 관심이 있는 코더도 있지만, 일반적으로 보안은 “다른 사람의 문제”라고 생각하는데, 여기에는 필연적으로 펜테스터도 포함됩니다.

대부분의 일반적인 취약점은 수정해야 할 사소한 문제입니다. 일단 알려지면 XSS (Cross-Site Scriptting) 및 SQL 삽입과 같은 수정 프로그램을 간단하게 실행할 수 있습니다... 문제는 많은 개발자들이 애초에 취약점을 도입했다는 사실을 깨닫지 못한다는 것입니다. 그리고 겉보기에 사소해 보이는 이러한 문제는 공격자가 회사에 치명적인 문제를 일으킬 수 있는 작은 기회입니다.아카마이에 따르면 2017년 11월부터 2019년 3월 사이에 SQL 인젝션 취약점이 발생했습니다. 전체 웹 기반 공격 벡터의 65%.이미 20년 넘게 해결된 것으로 알려진 취약점에 대한 통계는 냉정한 수치입니다.

일부 펜테스트 팀은 보안 버그 수정을 지원하지만, 다른 팀은 나쁜 소식에 대한 보고서를 제공하고 개발자가 핫픽스가 발생할 때 다른 프로젝트로 이동했더라도 핫픽스를 해결하기를 기대합니다.그리고 경우에 따라 개발팀은 수정할 수 없는 (또는 예상하지 못한) 버그가 포함된 보고서를 받게 될 수도 있습니다. 이 보고서는 여전히 발견의 일부여야 하며, 개인적으로 받아들여서는 안 됩니다.

이를 위한 “행복한 매개체”는 펜테스터, 보안 담당자 및 개발 관리자가 멘토 역할을 더 많이 맡아 팀이 효과적인 교육 및 도구 측면에서 필요한 것을 확보할 수 있도록 하여 개별 코더에게 SDLC 초기부터 성공하고 안전하게 코딩할 수 있는 최고의 기회를 제공하는 것입니다.건전한 DevSecOps 관행의 일환으로 처음부터 보안이 고려되도록 양 팀 모두 중간에 만나야 합니다.

“저는 제가 인정하는 것보다 훨씬 더 나은 보안 지식을 가지고 있습니다. 이러한 보고서는 대부분 오탐이거나 중요하지 않습니다.”

정적 분석은 SDLC의 보안 프로세스의 한 요소이며 정적 분석 스캐닝 도구 (SAST) 는 기본적인 역할을 합니다.그리고 네, 오탐지는 문제입니다 이러한 스캐너와 다른 유형의 스캐너 (DAST/IAST/RAST) 를 사용합니다.수동 코드 검토가 필요하고 개발자와 펜테스터 모두에게 압력을 가하기 때문에 이미 프로세스가 느리다는 점에서 성가신 일입니다.펜테스팅 담당자들은 부정확한 판독을 방지하기 위해 시간을 들여 사용자 지정 규칙을 세심하게 설정하고 회사별 지침을 제공했지만, 일부 잘못된 판독은 결국 머리를 긁는 개발자 앞에 놓이게 됩니다.

이 프로세스는 완벽하지는 않지만 또 다른 문제는 많은 개발자들이 많은 일반적인 취약점을 일관되게 완화할 수 있는 충분한 지식이 부족하다는 것입니다.고등 교육에서는 보기 드문 보안 교육과 실무 교육의 효과도 다양하기 때문에 일부 과신이 작용하고 있는 것은 당연합니다 (그리고 그건 그들의 잘못이 아닙니다. 업계로서 우리는 개발자들에게 필요한 것을 더 잘 제공할 필요가 있습니다).

“이 애플리케이션을 테스트하게 될 줄은 몰랐지만 이제는 수정 작업에 몰두하고 있습니다.”

때로 과로한 엔지니어들은 펜테스터가 애플리케이션을 테스트하고 개발팀의 퍼레이드에 비를 내리며 그저 날개에 매달려 있을 때를 기다리고 있을 뿐이라고 추측하기도 합니다.그들은 과잉 테스트하고, 빈약하고, 추가 작업을 만들고 있습니다.

유일한 문제는 그들 역시 과로하다는 것입니다 (사실 사이버 보안 기술 부족은 심각한 수준이고 점점 더 악화되고 있습니다) 그리고 단순히 이유 없이 테스트할 시간이 없습니다.테스트의 우선 순위를 결정하는 유일한 의사 결정자는 아닙니다. 고위 경영진이나 고객이 보안 감사의 일환으로 요청했거나 버그 바운티 프로그램의 결과로 확인되었을 수도 있습니다.

개발자의 경우 보안 수정 작업을 위해 현재 기능 구축 스프린트에서 제외되는 것은 성가신 일입니다. 특히 개발자의 작업이 아닌 경우에는 더욱 그렇습니다.아마도 이전 팀이 마지막 업데이트를 했거나 다른 공급업체가 진행했을 수도 있습니다.하지만 보안은 모두의 문제입니다.그렇다고 모든 개발자가 보안 버그를 자신이 직접 만든 것처럼 책임져야 한다는 뜻은 아닙니다. 하지만 보안이 공동 책임이라는 측면에서 각자 참여해야 한다는 뜻입니다.

여기서 어디로 갈까요?

때로는 사고 방식의 변화만으로도 문제를 해결하는 데 상당한 진전을 이룰 수 있습니다.펜테스트 결과가 좋지 않을 경우 개발자가 보이는 다소 냉담한 반응에 대해 이야기한 적이 있습니다. 하지만 개발자가 이를 도전으로 바꿀 수 있다면 어떨까요?아마도 그들은 펜테스터를 친근한 경쟁자, 즉 자신의 게임에서 이길 수 있는 사람으로 생각할 수도 있습니다.결국, 코드를 작성할 때 흔히 발생하는 버그를 제거할 수 있는 보안을 잘 아는 개발자는 작업을 훨씬 더 어렵게 만들 것입니다.반대로 보안에 초점을 두지 않는 개발자는 소프트웨어를 쉽게 망가뜨릴 수 있을 때 펜테스터 개발자에게 종합적으로 패배하게 됩니다.

펜테스터와 개발자가 100% 조화를 이루지는 못할 수도 있지만, 조직이 보안을 주요 우선 순위로 삼고 팀, 특히 개발자의 성공을 위한 올바른 지식과 도구를 제공할 때 관계가 크게 개선될 수 있습니다.결국 전사적 차원의 긍정적인 보안 문화가 우선 순위인지 여부가 관건이며, 일반적인 취약점을 상대로 (현재) 지고 있는 싸움에서 싸우고 싶다면 반드시 그래야 합니다.

코드 마이그레이션 (읽기: 레거시 코드) 은 재미가 없습니다.이 작업을 완료하려면 엄청난 계획과 노력이 필요합니다.개발자에게 가장 흥미롭거나 동기를 부여하는 작업은 아니지만 레거시 코드를 새 라이브러리 버전으로 마이그레이션하려면 결단력과 적절한 경험이 필요합니다. 조다 타임 java.time으로의 마이그레이션은 세심한 계획과 실행이 필요한 마이그레이션 중 하나입니다.

Java 프로젝트가 Java SE 8 이전에 시작되었고 날짜/시간 처리를 사용한다면 아마도 SE 8 이전의 날짜 및 시간 함수를 처리하기 위한 훌륭한 라이브러리이자 사실상의 표준인 Joda-Time을 사용했을 것입니다.프로젝트를 사용하는 경우 여전히 Joda-Time을 사용하지만 java.time으로 마이그레이션한 다음 계속 읽고 싶습니다.

Java SE 8의 릴리스에는 일반적으로 java.time (JSR-310) 이라고 하는 새롭고 개선된 표준 날짜 및 시간 API가 포함되었습니다.조다-타임 프로젝트는 이제 java.time (JSR-310) 으로의 마이그레이션을 권장합니다.

java.time (JSR-310) 은 Joda-Time에서 많은 영감을 얻었지만 이전 버전과는 호환되지 않으며 개념과 용어가 변경되었습니다.그렇기 때문에 Joda-Time에서 java.time으로 마이그레이션하려면 변경하는 코드 한 줄 한 줄에 주의를 기울여야 합니다.이렇게 하려면 시간이 오래 걸릴 수 있으며, 더 쉽고 자동화된 마이그레이션 방법이 있었으면 하는 생각이 들 정도입니다.

마이그레이션할 수 있는 더 좋은 방법이 있습니다. Sensei를 사용하여 만들었습니다. Sensei는 사용자가 정의한 레시피 (규칙) 에 따라 코드 변환을 자동으로 수행하는 IntelliJ 플러그인입니다.반복적인 마이그레이션 작업을 수행하는 대신 재사용 가능한 레시피를 정의하는 데 시간을 할애하세요.자동화는 기존 Joda-Time 코드를 변환할 뿐만 아니라 팀이 새 코드를 작성할 때 IDE에 있는 지침을 따르는 데도 도움이 됩니다.

보다 빠르게 시작할 수 있도록 Sensei 공개 요리책을 만들었습니다. 자바타임에 대한 표준화 (JSR-310) 여기에는 덜 고통스러운 방식으로 Joda-Time에서 java.time으로 마이그레이션하는 레시피가 포함되어 있습니다.이 레시피는 계속 늘어나고 있으며 앞으로도 계속 확장하여 더 많은 레시피로 더 많은 적용 범위를 넓힐 예정입니다.

다음은 Sensei를 사용하여 어떻게 레거시 코드를 쉽게 마이그레이션할 수 있는지 확인하는 데 도움이 될 수 있는 샘플 마이그레이션의 예입니다.

반복적인 수동 마이그레이션부터 자동 코드 변환까지

한 줄의 코드를 Joda-Time에서 java.time으로 마이그레이션할 때 숨겨진 몇 가지 함정을 보여주는 새 DateTime을 만드는 예제를 살펴보겠습니다.그런 다음 java.time 표준화 (JSR-310) 쿡북의 Sensei 레시피 중 하나를 살펴보고 모든 개발자가 동일한 마이그레이션을 반복해서 재사용할 수 있도록 이 모든 정보를 캡처하는 방법을 살펴보겠습니다.

이 예제에서는 DateTime 필드의 값을 나타내는 7 int 인수로부터 Joda-Time DateTime을 구성합니다.

이것을 java.time에 상응하는 것으로 마이그레이션하는 방법은 무엇입니까?

더 이 생성자를 위한 조다 타임의 javadoc 말한다:

기본 시간대의 IsoChronology를 사용하여 날짜/시간 필드 값에서 인스턴스를 구성합니다.

처음에는 다음과 같이 가정할 수 있습니다. 날짜/시간 java.time에는 클래스가 있지만 클래스가 없습니다.구글에서 '조다 타임에서 자바 타임으로 마이그레이션하기'를 검색해 보면 스티븐 콜본의 블로그 게시물을 찾을 가능성이 높습니다. 조다 타임에서 자바 타임으로 변환.

이것은 여러분에게 좋은 출발점이자 java.Time.ZonedDateTime 또는 java.Time.OffsetDateTime을 사용하는 방향을 제시해 줍니다.첫 번째 질문은 다음과 같습니다. 어떤 것을 사용해야 할까요?아마도 스티븐의 의견에 따르면 ZonedDateTime인 것 같습니다.

올려다보는 존 데이트타임 자바독, 생성자를 전혀 볼 수 없습니다.Stephen의 블로그 글로 돌아가서 아래 내용을 더 읽어 보겠습니다.

‍건설.Joda-Time에는 Object를 받아 형식 변환을 수행하는 생성자가 있습니다. java.time에는 팩토리 메서드만 있으므로 문자열에 parse () 메서드가 제공되지만 변환은 사용자 문제가 됩니다.

따라서 정적 팩토리 메서드가 있어야 합니다. 정적 메서드를 검색하면 꽤 비슷해 보이지만 완전히 같지는 않습니다.

오리지널 Joda-Time DateTime 생성자와 같은 7개의 int 파라미터를 가지고 있지만, 주의를 기울이지 않으면 중요한 세부 사항을 놓치게 됩니다.7번째 파라미터는 더 이상 밀리초를 나타내지 않고 나노초를 대신 사용합니다. 이는 java.time이 Joda-Time보다 정밀도를 높여 나노초까지 순간을 측정하기 때문입니다.쉽게 놓칠 수 있는 중요한 세부 정보입니다.또한 이 메서드에는 zoneID가 필요하기 때문에 이전에는 왜 필요하지 않았는지, 지금은 왜 필요한지 궁금해집니다.

기본 시간대를 사용한다고 언급한 원래 생성자의 javadoc을 기억하고 있는데, 기본 ZoneId를 가져오는 방법이 있을까요?

더 ZoneID를 위한 자바독 나열된 생성자에 대해서는 알려주지 않지만 정적 메서드를 살펴보면 사용할 수 있습니다. 시스템 기본값 ()

이제 ZoneId를 정리했으니 밀리초에서 나노초로의 변환은 어떻게 해야 할까요?아마도 java.util.Concurrent.TimeUnit을 사용하여 변환을 수행할 수 있을지도 모릅니다.

이 메서드는 long을 반환하고 메서드는 int를 예상하므로 이제 해결해야 할 변환 문제도 있습니다.간단한 것을 시도해 볼 수도 있겠네요.곱셈?

이것은 작동하겠지만 약간 어색해 보입니다.아직 눈치채지 못하셨다면, 저희는 코드 한 줄을 마이그레이션하는 데 상당한 시간과 노력을 들였습니다.하지만 상상할 수 있듯이 이러한 편집 작업을 수작업으로 수행해야 하는 경우가 많지만 더 나아질 수는 없습니다.

하지만 java.time API를 좀 더 자세히 살펴보면 좀 더 유창해 보이는 솔루션을 찾을 수 있습니다.

ZonedDateTime에는 밀리초를 설정하는 명확한 방법이 없지만 다음을 사용하여 설정할 수 있습니다. with (임시 필드 필드, 긴 새 값) 메서드, 사용 크로노필드. 밀리_오브_초 템포럴 필드로.

그리고 자바 문서는 우리를 위해 나노초로의 변환을 수행할 것이라고 언급했습니다.

이 필드를 사용하여 값을 설정하는 경우 값에 1,000,000을 곱한 NANO_OF_SECOND를 설정하는 것과 같은 방식으로 동작해야 합니다.

따라서 팩토리 메서드에서 나노초에 대해 0을 지정하고 다음을 사용할 수 있습니다. 와 원래 값과 밀리초를 모두 포함하는 ZonedDateTime을 만드는 메서드입니다.

최종 결과를 보면 코드 한 줄만 변경한 것처럼 보입니다. 단 한 번의 마이그레이션을 조사하는 데 들인 노력을 제대로 보여주지 못합니다!

‍

더 빠르고 쉽게 마이그레이션할 수 있는 레시피 만들기

Sensei는 어렵게 얻은 정보를 다른 개발자와 공유할 수 있는 방법을 제공합니다.이러한 모든 요구 사항을 담은 레시피를 만들면 Sensei 사용자는 마우스 클릭 한 번으로 이 마이그레이션을 수행할 수 있습니다.

Sensei 레시피는 세 가지 주요 섹션으로 구성됩니다.

• 메타데이터
• 검색
• 사용 가능한 수정

이 호출을 해당 java.time으로 마이그레이션하는 데 도움이 되는 Sensei 레시피 (YAML 레시피로도 볼 수 있음) 를 살펴보겠습니다.

DateTime foo = 새 날짜 시간 (년, 월, 월, 일, 시, 분, 분, 분 단위, 밀리초)

메타데이터 섹션

메타데이터 섹션에는 레시피에 대한 정보와 사용 방법이 포함되어 있습니다.

검색 섹션

Sensei 레시피의 검색 섹션은 이 레시피를 적용해야 하는 코드 요소를 지정합니다.

검색:
인스턴스 생성:
인수:
1:
유형: 정수
2:
유형: 정수
3:
유형: 정수
4:
유형: 정수
5:
유형: 정수
6:
유형: 정수
7:
유형: 정수
목표 개수: 7
형식: org.joda.time.DateTime

‍

이 검색 섹션에서 우리는 다음과 같은 것을 볼 수 있습니다:

• 검색 중 인스턴스 생성, 즉, 생성자의 사용.참고: 다음과 같은 것들이 있습니다. 다른 많은 검색 대상 사용 가능
• 생성자는 7개의 인수를 가져야 합니다. 이 인수는 다음과 같이 지정됩니다. 아그카운트 재산
• 인수 1-7은 int 유형이어야 합니다.
• 의 생성자를 찾고 있습니다. 유형 org.joda.time.DateTime

‍

사용 가능한 수정 섹션

AvailableFixes 섹션에서는 일치하는 코드 요소에 적용할 수 있는 수정 사항을 하나 이상 지정할 수 있습니다.각 수정에는 여러 작업이 포함될 수 있으며, 이 경우에는 2개의 작업을 수행하는 단일 수정이 있습니다.

‍

• 더 이름 수정 사항은 'Quickfix' 메뉴에서 사용자에게 표시되며 사용자가 이 퀵픽스를 적용하면 어떤 일이 발생하는지 설명합니다.
• 작업 목록에는 이 퀵픽스가 수행할 작업이 표시됩니다.
• 더 다시 작성하십시오 액션은 콧수염 템플릿을 사용하여 코드 요소를 다시 작성합니다.변수와 문자열 대체 함수를 사용할 수 있습니다.
• 더 할당된 변수 수정 액션은 이 생성자가 변수에 값을 할당하는 데 사용되고 있는지 확인합니다.그렇다면 이 작업을 수행하면 선언할 변수가 에서 지정한 유형으로 수정됩니다. 유형

‍

레시피를 사용하여 코드 변환 수행

레시피가 작성되고 활성화되면 코드를 스캔하고 적용할 수 있는 세그먼트를 강조 표시합니다.

아래 스크린샷에서 Sensei가 대상 생성자를 표시한 것을 볼 수 있습니다.표시된 생성자 위로 마우스를 가져가면 레시피, 단축설명 및 Quickfix 옵션이 표시됩니다. Java.Time.ZoneDateTime으로 마이그레이션

‍

우리가 선택한 후에 Java.Time.ZoneDateTime으로 마이그레이션 quickfix, 레시피에 지정한 작업에 따라 코드가 변환됩니다.

‍

Sensei를 통한 일회성 마이그레이션 및 팀 전반의 통일된 코딩 관행

위의 예에서 볼 수 있듯이 한 줄의 코드를 마이그레이션하려면 힘들게 얻은 지식이 포함될 수 있습니다.Sensei는 이러한 지식을 팀 내에서 공유할 수 있는 실행 가능한 레시피나 요리책으로 전환할 수 있습니다.일회성 마이그레이션 스프린트를 계획하거나 Joda-Time 코드를 접했을 때 java.time으로 점진적으로 즉시 변환하는 접근 방식을 취할 수 있습니다.논리적 단계 또는 단계별로 마이그레이션을 수행하는 방법으로 레시피를 활성화/비활성화할 수 있으며, Sensei에서 스캔한 파일의 범위를 확장하거나 축소할 수도 있습니다. 이러한 유연성은 코드 마이그레이션의 복잡성을 줄여줍니다.

라이브러리 마이그레이션은 Sensei를 사용하여 프로젝트를 표준화할 수 있는 다양한 방법 중 하나에 불과합니다.풀 리퀘스트나 직접 코딩할 때 자주 접하는 안티패턴 또는 특정 수동 코드 변환이 있는지 언제든지 확인할 수 있습니다.다음과 같은 세트를 가지고 있다면 코딩 가이드라인 개발자들이 놓치는 경우가 많지만 가이드라인을 레시피로 변환하여 개발자가 승인된 코드 변환을 자신 있게 적용할 수 있습니다.

질문이 있으시면 언제든지 연락주세요!다음 주소에서 Slack에 참여하세요. sensei-scw.slack.com

“마을이 필요해”라는 문구는 오래된 아프리카 속담, 다양한 아프리카 문화, 방언 및 지리적 위치에 걸쳐 있습니다.이 지혜의 진주를 전달하는 데 사용되는 언어는 다를 수 있지만 감정은 같습니다. 미래 세대를 다재다능한 성인으로 키울 수 있는 안전하고 긍정적이며 계몽적인 환경을 조성하기 위해서는 전체 커뮤니티의 의견이 필요합니다.

긴 인사를 건네는 것처럼 보일 수 있지만, 사실 개발자 커뮤니티는 바로 이 원칙에 따라 수십 년 동안 번창해 왔습니다.컴퓨터 뒤에 숨은 반사회적인 “고독한 늑대” 괴짜라는 개념은 대부분의 고정관념과 같습니다. 과장된 것이지 우리의 운영 방식을 배울 수 있는 최선의 방법은 아닙니다.각계각층의 다양한 유형의 개발자가 있으며, 우리가 하는 모든 일에는 항상 공동체 의식이 있었습니다.

인터넷이 일반화되기 오래 전부터 우리는 게시판에서 팁을 공유하고, 서로의 문제를 해결하고, 모범 사례를 놓고 논쟁을 벌였습니다 (그리고 확실히 제 편에서는 무언가를 깨기 위해 열심히 노력했습니다).이런 감정은 변함이 없습니다.이제 인터넷은 전혀 다른 것이 되었습니다. 다리 밑에 트롤이 더 많아지고 소음도 더 커지지만, 다음과 같은 곳으로 빠르게 뛰어들 수 있습니다. 레딧 과 스택 오버플로 기꺼이 도와주려는 의지, 동지애, 풍부한 정보를 즉각적으로 느끼게 해 줄 것입니다.

하지만 우리 모두가 지원할 수 있는 한 가지는 같은 일을 겪고 있는 사람들과의 실제 연결입니다.현실 세계에서 상호작용하면 새로운 차원의 의미가 생깁니다. “IRL” 커뮤니티를 활성화하면 놀라운 방식으로 지식 공유와 명확화를 가속화하고 시야를 넓힐 수 있습니다.

개발자 커뮤니티는 보안을 어떻게 지원하나요?

다음과 같은 조직 올말벌 취약점, 뉴스 및 중요 경보에 대한 풍부한 무료 리소스를 통해 보안 커뮤니티에서 놀라운 성과를 거두고 있습니다.오프라인에서는 전 세계 도시에 OWASP 지부가 있습니다. 이 지부에서는 사람들이 함께 모여 보안에 대해 이야기하고 소프트웨어를 더 안전하게 만들기 위한 팁을 공유할 수 있는 정기 행사를 주최합니다.정말 대단한 일이고, 제가 보기에 개발 커뮤니티의 전부라고 할 수 있습니다.

온라인이든 대면이든 이러한 커뮤니티가 해결하는 데 도움이 되는 한 가지는 개발자 간의 기술 및 지식 격차입니다.경험 많은 개발자들은 정보를 전달하거나, 누군가가 시작할 수 있도록 도와주거나, 올바른 방향으로 안내하는 데 너무 만족합니다 (훌륭한 제다이라면 누구나 때때로 파다완을 도와야 한다는 것을 알고 있습니다).

따라서 보안 코딩 토너먼트와 같은 행사를 주최하기 위해 그들과 파트너 관계를 맺을 수 있다는 것은 언제나 큰 기쁨입니다.지금까지 호주, 영국, 인도, 미국에서의 밋업을 지원해왔으며 앞으로도 더 많은 모임이 이어지기를 바랍니다.

OWASP 토너먼트 밋업은 어떤 모습인가요?런던의 상징적인 BBC 스튜디오에서 열린 OWASP 토너먼트 영상을 확인해 보세요.

이러한 이벤트는 인식을 제고하는 데 확실히 도움이 되며, 조직이 이러한 풀뿌리 이니셔티브를 지원하고, 완전한 보안 코딩 교육을 도입하고, 긍정적인 보안 문화로 운영하겠다는 약속을 할 때 이러한 모멘텀을 조직 내에서 활용할 수 있습니다.

어떻게 해야 할까요? 게임화 토너먼트는 더 안전한 개발자를 만드는 데 도움이 되나요?

OWASP 모임은 보안에 대해 잘 아는 다양한 사람들과 어울리고 지식을 공유하고 아이디어를 토론하는 것을 중심으로 구축되었습니다.그러나 보안이 처음이거나 아직 관심이 없는 사람에게는 이러한 이벤트가 눈에 띄지 않을 수 있습니다.

조직이 보안 인식을 제고하고 개발자 집단의 진정한 관심을 불러일으키는 데 적극적인 역할을 할 때, 우리가 얻어야 하는 보안 지식에 대한 평생 탐구를 심어주는 긍정적인 효과를 얻을 수 있습니다. 모두들 안전한 코딩에 대해 더 진지하게 생각하세요.

일반적인 교육 방법이 큰 동기 부여가 되는 경우는 드뭅니다 (예: 하루 일과가 쌓여 있을 때 교실에 앉아 있거나 끝없이 이어지는 비디오를 보면서 깨어 있으려고 하는 경우). 경쟁심을 불러일으키고 재미를 느끼며 과정을 게임화하면 학습이 훨씬 덜 번거로운 일이 될 수 있습니다.게임화된 학습 방법을 사용하면 기술적 지식 (때로는 건조한 지식) 을 훨씬 더 이해하기 쉽게 만들어 다음과 같은 작은 조각으로 나눕니다. 상황에 맞고 기억에 남으며 반복 학습을 장려합니다..Secure Code Warrior는 접근성을 기반으로 구축되었으므로 개발자는 자신의 창의성과 문제 해결에 대한 일반적인 본능을 반영하는 방식으로 이전에 배운 내용을 단계별로 계속 추가할 수 있습니다.

평가는 모든 구성원이 계획대로 진행하고 개선이 필요한 영역을 식별하는 데 도움이 되지만, 보안 코딩 토너먼트는 조직의 보안 인식과 긍정적인 변화를 위한 촉매제 역할을 할 뿐만 아니라 참가자가 자신의 탄탄한 기술을 과시할 수 있는 방법이기도 합니다.결국 토너먼트 순위표가 실시간으로 업데이트되는 것을 보면 계속해서 더 많은 포인트를 노리고 자신의 보안 능력을 과시하고 싶은 동기가 생깁니다.

성공적인 토너먼트는 어떤 모습일까요?

OWASP와의 만남 목적은 항상 보안 커뮤니티의 지속적인 건전성에 투자하여 보안에 대해 배우는 것이 실제로 재미있을 수 있다는 개념을 홍보하는 데 있습니다.

시큐어 코딩 토너먼트는 개발자들이 비슷한 생각을 가진 사람들과 소셜 환경에서 기술을 연마하고 실현할 수 있도록 도와줌으로써 참여도를 높이는 데 있어 당연한 일입니다.이는 아마도 직장이나 교육에서 유쾌하지 못한 경험을 바탕으로 “보안”이라는 개념을 둘러싸고 존재할 수 있는 인위적인 장벽을 허무는 데 도움을 줍니다.

정말 훌륭한 토너먼트는 일반적으로 다음과 같이 구성됩니다.

• 조직 전체에 약간의 열광을 퍼뜨리세요. 개발팀 외부 사람들에게 무슨 일이 일어나고 왜 일어나고 있는지 알려주세요.
• 판단이 필요 없는 환경, 모든 수준의 개발자 지원
• 몇 가지 특별한 혜택: 음식과 음료를 주문하고, 테마를 지정하고, 자기 표현을 장려하세요
• 보상과 포상; 우리 개발자들은 상품을 좋아하며, 우승자에게는 멋진 경품도 보너스입니다. 이 과정에서 미래의 보안 챔피언이 발굴될 수 있다는 점을 기억하세요.
• 공동체 의식과 동지애.

우리는 DevSecOps의 세계가 되고 있습니다. 마침내 소프트웨어 개발 프로젝트 초기부터 보안에 초점이 맞춰지면서 개발자들은 효과적인 교육을 통해 초기에 참여해야 합니다.이는 코드를 작성하는 순간부터 취약점으로부터 조직을 보호하는 데 필수적이며, 보안 문화가 번성함에 따라 누구나 조금 더 쉽게 안심할 수 있습니다.

이 기사의 한 버전이 에 게재되었습니다. 테크 크런치.여기에서 업데이트 및 신디케이트되었습니다.

‍

이름을 붙일 수 없는 해에도 충분한 혼란이 없었던 것처럼 2021년은 기록상 최악의 데이터 유출 사건으로 미국 정부의 귀가 먹먹해질 정도로 시작됐습니다.SolarWinds 사고는 파괴적이고 정교한 국가 공격으로, 몇몇 정부 부처와 대규모 조직을 공포에 빠뜨리고 엔드포인트를 확보하기 위해 분주하게 움직였습니다.SolarWinds 소프트웨어의 거의 모든 최종 사용자가 피해를 입었고, 이번 사건을 통해 소프트웨어 공급망의 사이버 보안과 방어가 매우 중요하다는 것이 분명해졌습니다.

사이버 보안이 중요하다는 것은 분명하지만 공급망의 맥락에서 실제로 의미하는 바는 무엇일까요?

일반 개발 팀의 사이버 보안 현황

매년 수십억 라인의 코드를 나타내는 엄청난 양의 소프트웨어가 매일 생산되고 있습니다. 이는 점진적인 디지털 라이프스타일로 인해 수요가 증가함에 따라 증가하고 있습니다.전 세계 개발자 인구는 다음과 같이 급증할 것으로 예상됩니다. 2024년까지 거의 2천 9백만그리고 현재로서는 안전한 코딩 능력을 평가하고 인증하기 위한 공식 인증은 없습니다.그렇다고 모든 개발자가 안전하지 않은 코드를 만들거나 재사용한다는 말은 아니지만, 우리가 데이터를 신뢰할 수 있는 소프트웨어에 기본적인 보안 약점이 도입될 수 있는 위험은 의심할 여지 없이 존재합니다.

개발자는 가능한 한 빨리 기능을 만들고 코드를 출시할 수 있는지 평가받습니다.대부분의 조직에서 보안이 성공의 벤치마크가 되지는 않았지만, 소프트웨어 개발 초기 단계에서 일반적인 보안 버그를 방지할 수 있는 잠재력을 깨닫는 기업이 늘어남에 따라 이러한 인식이 바뀌기 시작했습니다.하지만 구현과 구현은 서로 다른 문제이고, 대부분의 3차 개발 과정에서는 보안 코딩 관행에 대한 배경 정보를 생략하기 때문에 부족한 부분을 보충하는 것은 개발자의 작업장에 달려 있는 경우가 많습니다.기술 구축과 지식 공유가 드물거나 관련이 없다면 효과가 없을 것입니다.따라서 기술 개발 부족으로 인해 취약성이 반복되는 악순환이 끊어지지 않습니다.

당연히 전 세계의 사이버 보안 문제를 해결하는 것은 일반 소프트웨어 개발자의 책임이 아닙니다. 결국 조직에서 비용이 많이 드는 보안 전문가를 고용하는 데에는 이유가 있습니다.하지만 보안 전문가는 부족하기 때문에 개발자들이 이러한 부담을 줄이는 데 큰 역할을 할 수 있습니다.

하지만 치명적인 사이버 공격을 방지하는 측면에서 우리와 중요 인프라 및 민감한 조직을 위한 소프트웨어를 만드는 공급업체는 어떻게 될까요?이를 위해서는 최소한 소프트웨어 조달의 현재 상태를 바꿔야 할 것입니다.

안전한 소프트웨어 공급망을 가로막는 위험

체인은 가장 약한 연결 고리만큼만 강하다는 지겨운 격언은 안타깝게도 소프트웨어 공급에 있어서도 마찬가지입니다.회사가 보안 모범 사례 강화, 개발자 기술 향상에 대한 투자, 기능적인 DevSecOps 환경으로의 전환 (즉, 소프트웨어를 최대한 안전하게 만드는 데 대한 책임을 공유하는 모든 사람) 으로 전환했더라도 상관 없습니다. 보안 문제가 있는 공급업체의 소프트웨어를 사용하는 경우 해당 소프트웨어를 에코시스템에 상속하고 그에 따른 결과를 감수하게 됩니다.

물론 보안 팀은 기술 스택에 추가된 서드파티의 안전성을 평가하는 데 도움을 주어야 합니다. 하지만 솔루션 중에서 선택할 수 있는 옵션이 거의 없기 때문에 비즈니스 요구 사항을 기반으로 결정을 내릴 수 있습니다.이 시점에서 이는 신뢰를 쌓는 행위가 될 수 있습니다.공급업체도 귀사만큼 보안에 신경을 많이 쓰나요?그리고 당신만이 이해할 수 있는 위험과 보호해야 할 자산을 벤더가 실제로 평가할 수 있을까요?

투명성은 공급업체 소프트웨어 추가의 보안 가능성을 평가하는 데 있어 매우 중요한 요소입니다.그들도 그런가? 자체 보안 관행을 미리 파악합니다.?데이터를 안전하게 유지하기 위한 접근 방식에 자부심을 가져야 하며, 이를 최우선 과제로 삼아야 합니다.보안 관행이 어디에도 게시되어 있지 않거나 사용할 수 있는 정보가 없는 경우 보안을 최우선으로 고려하지 않을 가능성이 높습니다.공급업체는 기술 관련 질문에 답변할 수 있어야 하며 다음과 같은 독립 인증을 받아야 합니다. ISO27001 그리고 SOC2도 아프지 않을 것입니다.또한 내부 실사 및 보안 관행의 일환으로 “내부적으로 검토”하고 취약점을 검사할 수 없다면 잊어버리세요.

수요로 인해 소프트웨어 요구 사항의 구현이 빠르게 진행됨에 따라, 특히 공급업체 코드를 기존 시스템에 통합하여 새로운 컨텍스트에서 작업을 수행하는 경우 공급업체와 구매자 모두 업계 최고의 입지를 확보해야 합니다. 둘 다 출시하기 전에 일반적인 보안 버그와 결함을 찾아낼 수 있도록 개발자를 현장에 배치해야 합니다.기존의 기술 솔루션 스파이더 웹에 새로운 기능을 추가할 경우 수백, 수천 개의 종속성이 손상될 수 있으며, 작은 실패 하나가 심각한 실패로 이어질 수 있습니다.

그렇다면 해결책은 무엇일까요?모든 것을 처음부터 사내에서 코딩하시겠어요?1998년이었다면 말이 될 수도 있겠네요.하지만 더 이상 지브스에게 가장 가까운 세차장이 어디인지 묻지 않는 것처럼, 우리도 오늘날의 상황에 맞는 현실적인 안전 장치를 구현해야 합니다.

아직 은총알은 없지만 해결책이 있습니다

구매자의 경우 공급업체 소프트웨어 및 개발 관행에 대한 보안 평가를 전체 보안 프로그램 및 위험 완화 계획의 우선 순위로 삼아야 합니다.구매자의 인증, 사례 및 개발자의 보안 평판에 대해 질문하세요.

공급업체 (및 소프트웨어를 만드는 모든 회사) 는 보안이 최우선임을 입증할 준비가 되어 있어야 하며 기술 향상에 집중해야 합니다. 보안에 능숙한 개발자 수요가 많으며 적합한 도구 및 지원기존 팀에서 구축할 수 있으며 일반적인 취약점으로 인한 공격을 방어할 수 있습니다.하지만 기존 트레이닝을 그들에게 던지지는 마세요.기존 워크플로를 보완하는 보안 도구를 사용하여 번창할 시간을 주세요.최대한 쉽게 만들고 비즈니스를 지원하는 코드 사이에서 이러한 성가신 버그가 사라지기 시작하는 것을 지켜보세요.

결론은 소프트웨어 위험이 공급망의 일부일 경우 즉시 악화되어 취약한 구성 요소가 활용된 모든 사용자와 시스템에 영향을 미친다는 것입니다.공급업체가 소프트웨어를 구현하는 회사만큼 보안에 대해 진지하지 않거나 공급업체와 조직 모두 보안 프로그램이 부족한 경우 SolarWinds와 같은 더 파괴적이고 광범위한 공급망 공격은 필연적으로 표준이 될 것이며 이는 모두에게 심각한 문제입니다.