I must be a glutton for punishment. Not only was my first programming language IBM 360 Assembler, my second language was C. Programming anything in them wasn't easy. Programming safely in either is much harder.
So when the US Cybersecurity and Infrastructure Security Agency (CISA) and the FBI announced they were doubling down on their efforts to persuade software manufacturers to abandon "memory-unsafe" programming languages such as C and C++ for new code at least, it came as no surprise.
"난 아무래도 벌을 받고 있는걸지도 몰라. 처음 배운 프로그래밍 언어가 IBM 360 어셈블러였고, 두 번째 언어는 C였으니까. 둘 다 프로그래밍하기 쉽지 않았으니까. 게다가 안전하게 프로그래밍하는 건 훨씬 더 어려웠어
따라서 미국 사이버보안 및 인프라 보안국(CISA)과 FBI가 소프트웨어 제조업체들이 C나 C++와 같은 "메모리 안전성이 떨어지는" 프로그래밍 언어를 최소한 새로운 코드 작성 시에는 사용하지 않도록 설득하는 노력을 강화하겠다고 발표했을 때, 이는 전혀 놀라운 일이 아니었음."
In short, don't use C or C++. Yeah, that's going to happen.
If this sounds familiar, it's because CISA has been preaching on this point for years. Earlier in 2024, CISA, along with partner agencies including the FBI, Australian Signals Directorate's Australian Cyber Security Centre, and the Canadian Centre for Cyber Security, aka the Five Eyes, published a report, Exploring Memory Safety in Critical Open Source Projects, which analyzed 172 critical open source projects. The findings revealed that over half of these projects contain code written in memory-unsafe languages, accounting for 55 percent of the total lines of code across the examined projects.
결론부터 말하면, C나 C++는 쓰지 말라는거. ㅇㅇ, 그런 일이 벌어질거임.
이 내용이 낯설지 않다면, CISA가 수년 동안 이 점을 강조해 왔기 때문일거임. 2024년 초, CISA는 FBI, 호주 사이버보안국 산하 호주 사이버보안센터, 캐나다 사이버보안센터(일명 파이브 아이즈) 등 파트너 기관들과 함께 "핵심 오픈소스 프로젝트의 메모리 안전성 탐구"라는 보고서를 발표했음 . 이 보고서는 172개의 핵심 오픈소스 프로젝트를 분석한 결과, 절반 이상의 프로젝트에서 메모리 안전성이 확보되지 않은 언어로 작성된 코드가 포함되어 있으며, 이는 조사 대상 프로젝트 전체 코드 라인의 55%에 해당한다는 사실을 밝혀냈음.
If only it were that easy to snap your fingers and magically transform your code base from C to Rust. Spoiler alert: It's not.
"근데 손가락 하나 까딱하면 C 언어로 작성된 코드가 마법처럼 Rust로 바뀌면 얼마나 좋을까? 하지만 현실은 그렇지 않다는거임."
You see, people who've spent years and sometimes decades mastering C don't want to master the very different Rust. They don't see the point. After all, they can write memory-safe code in C, so why can't you?
"수년, 때로는 수십 년 동안 C 언어를 마스터해 온 사람들은 전혀 다른 Rust를 배우려 하지 않음. 그럴 필요성을 못 느끼는 거지. 어차피 C로도 메모리 안전성 코드를 작성할 수 있는데, 다른 사람들은 왜 그렇게 못하냐는거야"
Well, because they don't have those years of experience, for one thing.
It's more than just old, grumpy developers. Converting existing large codebases to memory-safe languages can be an enormous undertaking. It's time-consuming, resource-intensive, requires careful planning to maintain functionality, and, frankly, it's a pain in the rump.
Another problem is that memory-safe languages may introduce performance slowdowns compared to C and C++. There's a reason we're still using these decades-old, difficult languages; with them, developers can produce the fastest programs. Given a choice between speed and security, programmers and the companies that employ them go for the fastest code every time.
"일단 그들에게는 그만큼의 경험이 없기 때문임. (Rust 같은 안전한 언어 사용이)
단순히 늙고 심술궂은 꼰대들의 문제가 아님. 기존의 대규모 코드베이스를 메모리 안전 언어로 변환하는 것은 엄청난 작업이 될 수 있음. 시간도 많이 걸리고, 자원도 많이 소모되며, 기능 유지를 위해 세심한 계획이 필요하고, 솔직히 말해서 정말 골칫거리임.
또 다른 문제는 메모리 안전성을 중시하는 언어가 C나 C++에 비해 성능 저하를 초래할 수 있다는거야. 우리가 여전히 수십 년 된, 배우기 어려운 이 언어들을 사용하는 데에는 이유가 있음. 바로 개발자들이 이 언어들을 이용해 가장 빠른 프로그램을 만들 수 있기 때문임. 속도와 보안 중 하나를 선택해야 한다면, 프로그래머와 그들을 고용하는 기업들은 언제나 가장 빠른 코드를 선택할거임."
The CISA is insisting that this be done. Or, at the least, companies must come up with roadmaps for moving their existing codebases by January 1, 2026. The CISA argues that the long-term benefits in terms of reduced vulnerabilities and improved security outweigh the initial investment.
"CISA는 이러한 조치(안전한 코드 전환이)가 반드시 이루어져야 한다고 주장함. 그래서 최소한 기업들은 2026년 1월 1일까지 기존 코드베이스를 이전하기 위한 로드맵을 마련해야 함. CISA는 취약점 감소 및 보안 강화 측면에서 장기적인 이점이 초기 투자 비용보다 크다고 주장하기 때문임."
Eventually, painfully, slowly, we'll move to memory-safe languages. It really is a good idea. Personally, though, I don't expect it to happen this decade. In the 2030s? Yes, 2020s? No.
"결국, 고통스럽고 느리게, 우리는 메모리 안전성이 확보된 언어로 나아가야 될거임. 정말 좋은 생각이지. 하지만 개인적으로는 이번 10년 안에 그렇게 될 거라고는 기대하진 않음. 2030년대에는 가능할까? ㅇㅇ, 하지만 2020년대에는 아닐거임."
댓글 0