엘에스웨어 아카이브

1. ‘SBOM’ 기반의 SW 공급망 관리가 필요한 이유 AI 기반 개발, DevOps 자동화, 클라우드 네이티브 아키텍처가 일반화되면서 현대 소프트웨어의 70~90%는 오픈소스 컴포넌트로 구성된다. 문제는 “우리가 작성하지 않은 코드”가 서비스의 보안·법적 리스크를 좌우한다는 점이다. 2025년 Black Duck OSSRA 리포트 기준, 전 세계 엔터프라이즈 코드베이스의 86%에서 오픈소스 취약점이 발견되었으며, 이는 더 이상 선택이 아닌 필수 관리 영역임을 의미한다. 공급망 리스크는 대표적으로 다음 세 가지 축에서 발생한다.CVE 기반 보안 취약점 노출라이선스 컴플라이언스 위반서버·운영환경의 패키지 취약점 방치이 세 가지를 개별적으로 대응하는 방식은 한계가 있다. 이제는 SBOM 기반의 통합 거버넌..

보안취약점 진단분야는 보안에 있어서는 오래된 이야기 같지만 여전히 현재 진행형입니다. 국내 정보보호 분야 초창기부터 지금까지 꾸준히 진화해 왔지만, 최근 보안 위협의 수준이 달라지면서 우리의 접근법도 업그레이드가 필요한 시점입니다.전통적으로 IT 부서는 서버, 네트워크 장비, PC 같은 물리적 장비를 '자산으로 관리해 왔습니다. 재무 관점에서는 합리적이지만, 보안 관점에서는 충분하지 않다고 생각합니다.2025년 CISA KEV 분석 결과를 보면, VPN과 이메일 게이트웨이가 랜섬웨어 공격의 68%와 연관되어 있었습니다. 흥미로운 건, 이 취약점 대부분이 하드웨어 자체의 문제가 아니라 소프트웨어 구성, 관리 인터페이스 노출, 인증 설정 등의 허점에서 시작되었다는 겁니다. 이제는 전통적 IT자산 개념을 넘어..

소프트웨어는 더 이상 한 조직 안에서만 만들어지지 않습니다. 우리가 배포하는 제품의 상당 부분은 외부 오픈소스, 서드파티 라이브러리, 빌드·배포 자동화 도구, 클라우드 이미지로 이루어져 있습니다. 이 연결망이 바로 소프트웨어 공급망이고, 공격자들은 이 연결 지점의 패키지 저장소, 빌드 서버, 서명 키, 개발자 계정을 노려 제품 안으로 침입합니다. 이러한 때에 정부 조달 분야와 산업 전반에서 SBOM(Software Bill of Materials) 같은 공급망의 투명성을 제공하는 장치가 기본적인 요구사항으로 자리잡아 가고 있습니다. 미국 행정명령(EO) 14028은 SBOM을 “구성요소와 공급망 관계의 공식 기록”으로 정의하며 연방 조달에서의 중요성을 명확히 했고, NIST SSDF(SP 800‑2..

블랙덕(Black Duck)의 보고서 「임베디드 소프트웨어 품질 및 안전 현황 2025 (The State of Embedded Software Quality and Safety 2025)」는 임베디드 소프트웨어 전문가 대상으로 한 설문의 핵심 결과를 바탕으로 현재 일어나고 있는 상황에 대한 데이터 기반의 시각을 제공합니다. 보고서는 임베디드 소프트웨어 분야의 두 가지 중대한 변화를 배경으로 합니다. 첫째, AI 도구의 광범위한 도입과 그에 비해 위험할 정도로 미흡한 거버넌스 체계둘째, 소프트웨어 공급망이 핵심 비즈니스 기능으로 부상하면서 상업적 요구사항으로 자리잡은 소프트웨어 자재명세서(SBOM)또한 보고서에서는 임베디드 개발자의 역할 변화, 속도와 품질 사이의 지속적 긴장, 임베디드 소프트웨어 개발에..

1. ISMS-P 심사의 중요성과 기술적 요구사항 ISMS-P(Information Security Management System – Personal Information)는 와 를 기반으로 설계된 국내 인증제도로, 정보보호와 개인정보보호를 통합적으로 평가합니다. 최근 심사에서는 기술적 통제(Control)의 실효성 검증이 더욱 강화되었습니다. 단순한 정책 수립 여부 확인을 넘어, 운영 환경에서의 로그 증적, 보안 장비 설정값, 취약점 스캔 결과 등 실질적 증거 확보가 필수 요건으로 자리 잡았습니다.또한 NIST SP 800-53, OWASP Top 10, CVE/KVE 데이터베이스와 같은 글로벌 표준을 활용한 위험평가 수행 여부가 간접적으로 평가됩니다. 이는 국제적 수준의 보안 관리가 ISMS-P 인..

1. AI와 오픈소스, 개발의 새로운 표준 요즘 개발자라면 한 번쯤은 AI 코딩 도구(GitHub Copilot, ChatGPT, Cursor 등)를 써봤을 것이다. 몇 줄 입력만 해도 자동으로 코드가 생성되고, 개발 속도는 몇 배 이상 빨라진다. 하지만 여기에는 중대한 리스크가 숨어 있다.AI가 제안한 코드에 오픈소스가 섞여 있을 수 있고,그 코드가 보안 취약점을 내제하고 있을 가능성도 크다.더 나아가, 라이선스 충돌이 발생하면 기업은 법적 분쟁까지 직면할 수 있다.이 문제를 해결하기 위한 가장 확실한 방법은, 새로운 개발 패러다임에 대응 가능한 관리 시스템을 구축하는 것이다. 여기에서는 포세라(FOSSEra)와 블랙덕(Black Duck)을 결합한 통합 오픈소스 관리 솔루션 포세라 위드 블랙덕을 활용..

1. 서론: 왜 우리는 AI의 설명을 들어야 하는가? 인공지능(AI) 모델이 점점 더 복잡해지면서 그 의사결정 과정이 '블랙박스'처럼 불투명해지는 문제가 대두되고 있습니다. AI가 단순히 데이터를 분류하는 것을 넘어, 기업의 보안 시스템을 통제하고 잠재적 위협을 판단하는 중추적인 역할을 맡게 되면서, 우리는 AI의 '결정'뿐만 아니라 그 '이유'를 알아야 할 필요성에 직면했습니다. 특히 금융, 의료, 국방, 그리고 사이버 보안처럼 높은 수준의 책임과 신뢰가 요구되는 분야에서 AI의 판단 근거를 이해하는 것은 선택이 아닌 필수입니다. 이 아티클은 AI의 투명성과 신뢰성을 확보하기 위한 핵심 기술인 '설명 가능한 AI(eXplainable AI, XAI)'의 개념과 최신 기술 동향을 심도 있게 다룹니다...

1. 서론 일반적으로 소스코드 불법 복제 또는 개작 행위는 유사 또는 동일한 기능을 불법으로 쉽게 구현하기 위한 방법으로 사용되므로, 동일․유사 기능에 해당하는 소스파일끼리 파일비교쌍을 만들어 비교하는 것이 효과적이다. 마찬가지로, 실행코드의 경우에도 동일․유사 기능에 해당하는 역어셈블 코드끼리 비교하는 것이 효과적이다. 다만, 상위수준 언어로 개발된 원 소스코드의 경우에는 특정 기능에 해당하는 소스코드 분석 및 추출이 용이한 반면 컴파일된 형태의 실행코드는 해당부분의 분석 및 추출이 어렵다. 실행코드의 유사도를 효과적으로 비교하기 위한 여러가지 비교 항목을 분류해 보았다. 2. 관련 기술 소스코드의 실행문과 비실행문을 대상으로 이루어지는 복제여부는 라인이나 토큰(Token) 단위의 비교를 통해서 ..

엘에스웨어의 공식 블로그가 네이버와 티스토리에 신규 오픈했습니다!🎉 티스토리 에서는 전문성 높은 IT 기술 아티클이 연재될 예정입니다. 엘에스웨어의 뉴스와 행사 소식은 네이버 공식 블로그에서 확인해 주세요. ​많은 관심 부탁드립니다.감사합니다. ​​ps. 엘에스웨어의 역사가 궁금하다면 기존 엘에스웨어 블로그에서 확인하세요!