보안 코드 인사이트

It's no secret that our main mission is to make software and its development safe; crafted with security in mind from the very beginning of production. Our vision sets a new benchmark for software creation, where developers are empowered with the skills and knowledge detect vulnerable code during the writing process and fix it before it even becomes an issue.

So, with that in mind, you may think we're delighted to hear of new data breaches, cyber attacks and exploited code affecting companies all over the world - those incidents certainly highlight the need for our service in multiple verticals. The truth is, it's quite frustrating. It's clear that as an industry we are making the same mistakes time and time again, because most security education just isn't robust enough to minimise risk and stop these breaches.

The latest data breach victim is Ticketmaster. If you were among the thousands of affected customers, you'd have received an email notifying you of the incident and to change your password. No-one expects to have their personal data violated simply for buying tickets to a concert or sporting event, yet here we are.

It's an awful situation for everyone; detrimental to Ticketmaster's reputation and a downright rotten customer experience. There's one problem, though: it wasn't entirely their fault.

You see, the company utilised the services of a third-party customer support application from Inbenta Technologies. Ticketmaster UK discovered that the product contained malicious code, leading to five percent of their global customer data being compromised.

And how exactly did hackers manage to exploit this system? They manipulated a single line of JavaScript code, customized by Inbenta Technologies for Ticketmaster's requirements. According to Inbenta, the code was used on a page it was not built to accommodate, and had they known, would have identified it as a security vulnerability.

The vulnerability itself is essentially a file upload/storage library security issue, wherein just one breach can affect every site on which the same code is loaded. The code can be modified to collect and reroute personal data to the attackers, just for starters. This is a simple exploit with far-reaching damage potential, and it is something we are working on defending against with a range of in-platform training exercises for developers.

Of course, it's virtually impossible to run a business without relying on some third-party applications. However, you have no control over how they build their software, and essentially zero visibility on the security strength of their code. It becomes a trust exercise. If your third-party partner is lax in their secure coding practices, you may be opening the door to a breach in yourcompany.

So, what's the solution? Put simply: we all must do better. We must stop thinking of security as an irritating obstacle on the path of company innovation.

It is easier than you think to empower your dev team with the right tools and knowledge to embrace security, stopping bad code in its tracks. We have been pleased to see so many of the worlds largest and most well-known financial, telecommunications, retail and tech companies adopt this new approach, but it shouldnt be the sole domain of Fortune 100 companies to take steps in security education. Every company that counts developers among their staff needs to implement training to help teams code securely.

The recently released white paper I wrote in conjunction with our CTO Matias Madou, showcases the benefits of building a security culture in your organisation. We detail why it is the key to unlocking innovation, staying agile and reducing the financial impact of insecure code.

You'll find tips including:

* How to make security training relevant and engaging for developers

* How to teach developers to identify and fix their own issues

* How to help developers securely construct their own code.

I invite you to download this resource and use it to champion security in your organisation, build the skills of your team and be at the forefront of setting a higher standard of code.

We must stop thinking of security as an irritating obstacle on the path of company innovation.

If I asked you how much it would cost to change just one line of computer code in a device that's already in service, what number would come to mind? A few hundred dollars? Maybe thousands?

According to Aviation Today, it costs $1 million for a commercial airline to update a line of code in its planes. For a cost so substantial, they would likely need a compelling reason to take the steps required to make any update to their airplane's systems, which really got me thinking about a number of factors.

Breaking down the cost

While the article doesn't outline what comprises the $1 million cost, I think it's a viable figure. I'm not an expert specifically in airline software updates, but I can assume a few of the steps the airline is forced to take in this situation.

First, the airline needs to discover a flaw or vulnerability that necessitates the update. The cited example consists of research performed by the U.S. Department of Homeland Security (DHS)  on a Boeing 757. The results - a remote hack after only two days of work - are more than compelling enough for any airline to take note.

From there, software developers need to analyze the findings, write new code, and test it in a safe environment to ensure the issue is fixed. Now comes the tricky part. The airline needs to ground each vulnerable or flawed aircraft, apply the new code, test it to ensure it works with that specific plane, and then recertify that plan for commercial flight.

According to airfleets.net, Southwest Airlines currently has 499 Boeing 737-700 planes in its fleet. Consider the time and money investment involved if a security flaw emerged in this particular plane model.

Not just an airline challenge

Clearly, airlines should have a vested interest in employing sound secure coding principles from the start. After giving it a few moments'thought, I could see numerous industries and situations where a similar cost might apply. Instead of worrying about airplanes falling out of the sky due to a hacked vulnerability, what about medical devices like pacemakers? How much does it cost to recall and update a half-million lifesaving pieces of electronics?

In the automotive industry, we continue to hear talk and security concerns about self-driving cars. Yet, even our "typical'vehicles rely more heavily than ever on connectivity to the internet, which leads directly to some troubling - if entertaining - safety concerns.

It's a simple fact that it costs much more money and takes more effort and time to update devices or systems after they've been released into a production environment, or before they've been mass produced, than it does to build security into your initial development process. Yet, we still continue to see new preventable software flaws and cybersecurity vulnerabilities every day, underscoring the need for companies to look for ways to build secure software development into their development culture.

The cost to change one line of code on a piece of avionics equipment is $1 million, and it takes a year to implement. For Southwest Airlines, whose fleet is based on Boeing's 737, it would "bankrupt" them if a cyber vulnerability was specific to systems on board 737s

‍

이번 달 초에 저는 참석할 기회가 있었습니다 OWASP 앱섹 데이 2019 아름다운 멜버른에서개발자 중심의 이러한 이벤트는 일정에서 제가 가장 좋아하는 행사 중 하나입니다. 소프트웨어 엔지니어와 전문가를 교육하고 역량을 강화하여 업무의 보안을 옹호하기 위해 끊임없이 노력하는 커뮤니티를 겸손하게 상기시켜줍니다.

게스트 라인업은 놀라울 정도로 다양하다는 것은 말할 것도 없고, 놀라울 정도로 다양했습니다. 업계에서 몇 년을 보낸 후에도 저도 영감을 받을 수 있다는 것이 정말 좋은 느낌입니다.다음과 같은 타냐 얀카, 토니 제임스 과 테리 라디첼 놀라운 프레젠테이션을 제공하면서 와이어구울“Eldar Marcussen Eldar는 현장 보안 코딩 과제에 대해 강당 전체를 테스트했지만 참석자들 사이에서 보안 의식이 깊어지는 것을 목격할 수 있어서 정말 좋았습니다.

올해 시큐어 코드 워리어는 이 행사의 플래티넘 스폰서였습니다.불과 4년 전만 해도 OWASP AppSec Day를 만든 팀이 무료 부스와 프로모션을 통해 부트스트랩 스타트업을 도왔다는 사실을 떠올리며 미소를 지을 수밖에 없었습니다.회사로서 우리가 얼마나 발전했는지 보는 것은 자랑스러운 순간이었고, 놀라운 사람들로 구성된 관대한 커뮤니티가 존재한다는 것에 감사할 수 있는 시간이었습니다.

토니 제임스: 개발자 관점에서의 보안

이 세상에서 우리가 더 키워야 할 것이 하나 있다면 바로 공감입니다.소프트웨어를 전반적으로 더 안전하게 만들기 위해서는 개발자가 처한 곤경을 이해하는 것이 필수적입니다.

Toni의 프레젠테이션이 정말 즐거웠고, 모든 개발자들이 즉시 공감할 수 있었을 거라고 확신합니다.이 이야기에는 단순히 “보안 코드 작성” 외에도 훨씬 더 많은 내용이 담겨 있습니다. 보안 교육을 효과적으로 받은 개발자들이 취약점을 퇴치할 수 있는 가장 좋은 기회라고 생각하긴 하지만, 그들이 매일 겪는 어려움을 반드시 고려해야 합니다.

소프트웨어 개발자의 작업은 수백만 명의 사용자에게 전시될 수 있고, 중요한 인프라를 지원하며, 우리가 당연하게 여기는 서비스의 원동력이 될 수 있습니다.기능 구축, 비즈니스 혁신 실행, 간결한 납품 기한 준수 등은 엄청난 압박을 가중시킵니다. 이는 AppSec 팀이 대규모로 자리를 잡고 각자의 힘든 일을 골라내기 전입니다.Toni는 이러한 환경에서의 삶이 어떠한지, 그리고 모든 측면에서 충분한 공감이 얼마나 더 나은 프로세스와 보안 결과로 이어질 수 있는지에 대해 이야기했습니다.개발자와 AppSec 팀 간의 격차를 해소하기 위해 이렇게 건강한 진전이 이뤄지는 것을 보게 되어 매우 기쁩니다. 결국 이는 긍정적이고 번성하는 보안 문화의 중요한 요소이며, Toni는 이러한 프로세스가 놀라울 정도로 잘 작동하는 대표적인 예입니다.

타냐 얀카와 테리 라디첼: 보안 슈퍼히어로

대회라는 것은 아니지만, 타냐 얀카와 테리 라디첼이 컨퍼런스에 기여한 것 중 하나는 제가 가장 좋아하는 것 중 하나였습니다.DIY 클라우드 보안 평가에 대한 튜토리얼을 시작한 지 10분 만에 놀라울 정도로 폭넓은 경험, 자격 및 전문성을 드러냈을 뿐만 아니라 지식을 공유하고 개발자 커뮤니티를 지원하려는 진정한 따뜻함과 열망도 드러났습니다.이들은 함께 보안 정책 설정 및 최소 권한 조치에 대한 실질적인 조언을 포함하여 Azure 구현의 보안을 보장하기 위한 현실적이고 실행 가능한 조치를 제시했습니다.

Google에서 빠르게 검색하면 소프트웨어 보안의 재미있고 매력적인 측면을 홍보할 수 있는 풍부한 무료 리소스, 멘토링 기회, 인터뷰를 통해 풀뿌리 차원에서 개발자를 지원하기 위한 노력에 대해 알아야 할 모든 것을 알 수 있습니다.그들은 우리 커뮤니티에서 영감을 주고 중요한 역할을 하는 챔피언입니다. 여러분이 참석하는 다음 보안 컨퍼런스에서 그들이 연설을 한다면 그들의 세션을 놓치게 되면 화가 날 것입니다.

큰 무대에 선 고객들

많은 고객이 참석했을 뿐만 아니라 무대를 소유하고 청중과 엄청난 보안 지식을 공유하는 모습을 볼 수 있어서 정말 기뻤습니다.

우리는 그럭저럭 잡을 수 있었습니다. 텔스트라앤드류 베일리가 “DevOps에 “섹션 추가”라는 중요한 강연을 하고 있습니다.선임 소프트웨어 엔지니어로 일한 풍부한 경험을 바탕으로 현재는 애플리케이션 보안 및 보안 코딩에 초점을 맞추고 있다는 점은 강조할 만한 훌륭한 관점이었습니다.그는 SDLC의 모든 단계에 보안을 주입하는 방법에 대한 포괄적인 팁을 제공했습니다 (물론 처음부터 보안 코딩에 대해 더 많은 개발자를 교육하는 것도 포함됨).

켄 존슨은 의 일원입니다 깃허브의 보안 팀, 그리고 컨퍼런스가 끝날 무렵 그가 전문가 패널에 합류하는 것을 보게 되어 기뻤습니다.그는 다른 패널들과 함께 미디어에서 마땅히 받아야 할 관심을 받지 못하는 사람들을 포함하여 청중의 긴급한 질문에 너무 기쁜 마음으로 대답했습니다.그는 패널로 하여금 여러 업계 인사이트와 함께 개발자 번아웃의 시대에 매우 중요한 웰빙과 일과 삶의 균형의 중요성에 대해 이야기하도록 했습니다.

또 다른 멋진 컨퍼런스에 대해 줄리안 버턴과 OWASP 멜버른 팀 전체에게 큰 감사를 표하고 싶습니다.내년에 만나요 (스티커 추가 포함).

저는 최근에 인터뷰를 받았습니다. 실버 불릿 팟캐스트Gary McGraw가 주최한 이 자리에서는 학술 연구에 비해 산업이 갖는 이점, 유럽에서 사업을 시작하는 것이 쉬운 이유, 애플리케이션 보안 산업이 미래에 나아갈 방향에 대해 논의했습니다.

창업을 하려는 의도는 전혀 없었지만, 같은 문제로 어려움을 겪고 있는 회사가 너무 많아서 창업하게 되었습니다. 보안 코드를 작성하는 것은 대부분의 개발자에게 어려운 일입니다.업계 전체가 코드의 보안 문제를 찾는 데 집중하고 있는데, 이런 문제들은 계속 쌓여가고 있습니다.

발견된 문제를 해결하는 데 어려움을 겪는 조직과 개발 팀을 효율적으로 돕는 데 초점을 맞춘 솔루션은 거의 없으며, 코드에 더 많은 문제가 유입되는 것을 방지하는 데에는 더더욱 초점을 맞추고 있습니다.점점 더 많은 조직에서 이러한 악순환을 인식하고 있으며 개발 팀은 처음부터 보안 코드 작성에 대한 교육을 받아야 하며 이를 가능하게 하는 도구와 프로세스를 갖추어야 한다는 사실을 깨닫고 있습니다.

Gary McGraw와 제가 이 업계의 발전을 어떻게 보고 있는지 더 알고 싶다면 다음 사이트를 확인해 보세요. 실버 불릿 팟캐스트!

쇼 139: Matias Madou가 보안 개발 교육 및 소프트웨어 보안 테스트 연구에 대해 이야기합니다.

https://www.synopsys.com/software-integrity/resources/podcasts/show-139.html

점점 더 혼란스러운 이 세상에서 사람들이 믿고 의지할 수 있는 몇 가지 변함이 항상 존재해 왔습니다. 아침에는 해가 뜨고 밤에 다시 질 것이고, 마리오는 언제나 소닉 더 헤지호그보다 더 차갑고, 인젝션 공격은 오픈 웹 애플리케이션 보안 프로젝트 (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는 보안 챔피언을 식별하고 개발자와 조직이 오늘날의 끊임없이 변화하는 보안 문제를 해결하는 데 필요한 적절한 기술을 갖추도록 도와줍니다.

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