A Qualitative Study of Dependency Management and Its Security Implications를 번역한 글입니다.
Pashchenko, Ivan, Duc-Ly Vu, and Fabio Massacci. "A qualitative study of dependency management and its security implications." Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security. 2020.
A Qualitative Study of Dependency Management and Its Security Implications
종속성 관리 및 보안 영향에 대한 정성적 연구
ABSTRACT
Maven, NPM 및 Android 생태계에 대한 여러 대규모 연구에서는 많은 개발자가 취약한 소프트웨어 라이브러리를 자주 업데이트하지 않아 코드 사용자가 보안 위험에 노출된다는 점을 지적합니다. 이 연구의 목적은 소프트웨어 종속성을 선택, 관리 및 업데이트하기 위한 개발자의 전반적인 의사 결정 전략에 대한 기능 및 보안 문제의 선택과 상호 작용을 질적으로 조사하는 것입니다.
우리는 9개국에 위치한 대기업 및 중소기업 개발자들과 25회의 반구조화된 인터뷰를 진행합니다. 모든 인터뷰는 응용 주제 분석에 따라 전사, 코딩 및 분석되었습니다. 개발자가 직면하고 있고 보안 연구원이 취약성을 완화하기 위한 효과적인 지원을 제공하기 위해 이해해야 하는 절충안을 강조합니다(예: 기능 변경 사항과 함께 보안 수정 사항을 번들로 제공하면 기능적 주요 변경 사항을 수정하기 위한 리소스가 부족하여 채택을 방해할 수 있음).
우리는 (반)자동 종속성 관리를 효과적으로 지원하기 위해 어떤 알고리즘과 자동화된 도구가 달성해야 하는지에 대한 실행 가능한 의미에 대한 관찰을 더 정제합니다.
1 INTRODUCTION
취약한 종속성은 소프트웨어 생태계에서 알려진 문제[25, 33]입니다. 왜냐하면 무료 및 오픈 소스 소프트웨어(FOSS) 라이브러리는 고도로 상호 연결되어 있고 개발자는 알려진 보안 취약성의 영향을 받더라도 프로젝트 종속성을 업데이트하지 않는 경우가 많기 때문입니다[11, 25].
소수의 연구에 따르면 개발자는 종속성 문제를 인식하지 못하거나[6] 프로젝트를 중단하고 싶지 않기 때문에 프로젝트의 종속성을 업데이트하지 않습니다[7, 16]. 기능과 보안이 개발자의 결정에 영향을 미치는 필수 요소인 것처럼 보이지만[3], 이러한 연구는 주로 기능 측면에 초점을 맞추므로 보안 문제가 개발자의 추론에 미치는 영향에 대한 제한된 통찰력을 제공합니다.
다른 연구에서도 기능과 보안 사이의 이러한 긴장을 보여줍니다. Android 생태계에서 모바일 앱 개발자는 보안을 최우선 과제로 생각하지 않습니다[11]. 같은 그룹[20]의 이후 연구에서는 그 이유를 기능과의 주요 충돌로 설명했습니다. '쉬운' 업데이트는 실제로 종속 프로젝트의 약 50%를 중단합니다.
주요 관찰은 이러한 연구 중 일부가 앱 종속성을 저장하고 관리하기 위한 중앙 위치를 특징으로 하지 않는 생태계에 관한 것입니다. Maven, NPM 또는 PyPI와 같은 중앙 종속성 관리 시스템을 사용하는 개발자는 애플리케이션의 종속성에 대해 매우 다른 접근 방식을 사용할 수 있습니다.
예를 들어, Maven 생태계에 대한 초기 양적 연구[25]는 4600개 이상의 Github 리포지토리를 분석했으며 개발자가 프로젝트 종속성을 구식으로 유지한다는 또 다른 증거를 제공했습니다. 그러나 이후 연구[33]에 따르면 보고된 취약점 중 몇 가지가 테스트/개발 라이브러리(즉, 제품과 함께 제공되지 않음)에 있으므로 관련이 없습니다. 따라서 라이브러리를 업데이트하지 않은 것은 기능과의 심각한 충돌 때문이 아니라 완벽하게 합리적인 결정 때문이었습니다.
우리 논문의 목표는 엄격한 형식의 설문조사(예: [11])와 종속성에 대한 정량적 연구를 보완하는 일화적인 예(예: [25]) 사이에서 개발자의 동기에 대한 건전한 정성적 분석을 제공하는 것입니다.
반구조화된 인터뷰 과정에 따라 우리는 다음과 같은 연구 질문을 조사했습니다.
- RQ1: 개발자는 프로젝트에 포함할 종속성을 어떻게 선택하고 보안이 역할을 하는 곳(만약 있다면)은 무엇입니까?
- RQ2: 개발자가 소프트웨어 종속성을 업데이트하기로 결정한 이유는 무엇이며 보안 문제가 결정에 어떤 영향을 미칩니까?
- RQ3: 개발자가 적용하는 동안 어떤 방법, 기술 또는 자동화된 분석 도구(예: Github Security Alerts)가
- (취약한) 소프트웨어 종속성을 관리합니까?
- RQ4: 개발자가 취약한 경우 어떤 완화 조치를 적용합니까?
- 사용 가능한 고정 버전이 없는 종속성? 이 문서에는 다음과 같은 기여가 있습니다.
- 소프트웨어 종속성을 선택, 관리 및 업데이트하기 위한 개발자의 전반적인 의사 결정 전략에 대한 기능 및 보안 문제의 선택과 상호 작용에 대한 정성적 조사
- 보안 및 (반)자동 종속성 관리 지원을 개선하는 데 도움이 되는 연구 및 실습에 대한 가능한 의미.
우리의 질적 연구는 웹, 임베디드, 모바일 또는 데스크탑 애플리케이션 개발에 참여하는 25명의 엔터프라이즈 개발자와의 반구조화된 인터뷰를 기반으로 합니다. 일부 인터뷰 대상자는 자체 라이브러리를 만들기도 하지만(즉, 다른 프로젝트에 종속성을 제공함) 초점을 유지하기 위해 인터뷰에서는 라이브러리 수요에서 자신의 역할을 조사했습니다. 인터뷰 대상자는 Java 사용자 그룹의 코디네이터와 Linux 배포판의 수석 개발자를 포함하여 일반 개발자에서 회사 CTO에 이르기까지 다양한 직책에서 최소 3년의 전문적인 경험을 가지고 있습니다. 그들은 9개국에 위치한 25개 회사에서 왔습니다.
각 인터뷰(평균 30분 지속)를 녹음하고 전사했습니다. 녹취록은 익명으로 처리되었으며 확인을 위해 인터뷰 대상자에게 다시 전송되었습니다. 그런 다음 각 대화는 수집된 정성적 데이터에 대한 정량적 평가를 제공하기 위해 적용된 주제 분석 라인을 따라 코딩되었습니다.
이 백서는 소프트웨어 종속성과 보안 문제가 결정에 미치는 영향을 관리하면서 개발자의 추론을 더 잘 이해할 수 있도록 인터뷰 대상자의 인용문과 함께 통찰력을 보여줍니다1. 분석을 완료한 후 전체 결과를 참여 개발자에게 반환하여 우리가 그들의 생각을 잘못 해석하지 않았는지 확인했습니다.
2 TERMINOLOGY(용어)
우리는 실무자들 사이에서 확립된 용어에 의존합니다:
- 라이브러리(library)는 별도로 배포되는 소프트웨어 구성 요소입니다. 다른 소프트웨어 프로젝트에서 재사용할 수 있는 기능
- 종속성(dependency)은 다른 소프트웨어 프로젝트에서 일부 기능을 재사용하는 라이브러리입니다. "의존성"은 논리적으로 관계와 관련이 있지만 소프트웨어 개발자2가 사용하는(및 남용하는) 용어를 채택하여 2에서 전달된 생각의 의미를 올바르게 전달할 수 있습니다. 나중에 논문에서 인용 형식.
- 종속성 관리(dependency management)는 업데이트(즉, 현재 사용되는 종속성의 새 버전 채택) 또는 종속성을 추가/제거하여 프로젝트 구성. 종속성을 관리하기 위해 소프트웨어 개발자는 프로젝트의 자체 코드만 수정하면 됩니다.
- 종속성 유지(dependency maintenance)는 프로젝트 종속성의 소스 코드에 대한 액세스 및 수정을 의미합니다. 종속성 유지를 위해 개발자는 일반적으로 종속성 소스 코드 저장소(예: Github 저장소)에 액세스하고 종속성 프로젝트에 기여해야 합니다(예: 제안된 변경 사항의 풀 요청 생성).
3 BACKGROUND
최신 기술을 이해하기 위해 Elsevier Scopus에서 2006년에서 2019년 사이에 발행된 논문에서 2절에서 식별된 코드 그룹 중 하나에 대한 결과를 보고하고 설문조사, 인터뷰, 사례 또는 정성적 연구 등을 언급하는 논문을 찾았습니다. 159개 기사의 예비 선택에서 25개로 좁혔습니다(익명의 검토자의 제안 포함). 모든 논문의 비교 분석은 부록의 표 7에 나와 있습니다.
3.1 Dependency management and mitigation of dependency issues.
많은 실증 연구[2, 8, 9, 19, 22, 25, 26, 28, 33, 35, 36, 44]에서 소프트웨어 종속성으로 인해 발생하는 보안 취약성에 대해 조사하고 있습니다. Cox et al. [9]는 "종속 신선도"의 개념을 도입하고 새로운 종속성이 보안 취약성에서 자유로울 가능성이 더 높다고 보고했습니다. 그러나 Java[25, 33], JavaScript[19, 22, 44], Ruby[22], Rust[22] 등과 같은 서로 다른 종속성 생태계에 대한 다양한 연구는 개발자가 자주 사용한다는 증거를 제공합니다. 소프트웨어 종속성을 업데이트하지 마십시오.
Derr et al. [11] Android 개발자를 대상으로 설문조사를 통해 라이브러리 사용 및 보다 효과적인 라이브러리 업데이트 요구 사항을 확인했습니다. 앱 라이브러리를 업데이트할 때 개발자는 보안이 작은 역할을 하는 동안 버그 수정을 가장 중요한 이유로 고려합니다. 개발자는 의도한 대로 작동하는 경우 종속성을 업데이트하는 것을 경계합니다. 후속 양적 연구[20]에 따르면 개발자가 종속성을 업데이트하지 못하게 하는 가장 큰 이유는 더 이상 사용되지 않는 기능, 변경된 데이터 구조 또는 서로 다른 라이브러리와 호스트 앱 간의 얽힌 종속성으로 인한 변경 사항을 깨는 것입니다. 각 종류(기능 또는 보안)의 업데이트를 수행하려는 개발자의 동기에 대한 제한된 통찰력이 제공됩니다. 또한, 본 연구는 Maven Central, NPM, PyPI와 같이 중앙 종속성 관리 시스템이 없는 Android 생태계의 결과를 제시했기 때문에 결과가 다른 생태계 개발자에게 일반화되지 않을 수 있습니다.
Haenni et al. [16]은 종속성을 업데이트할 때 주요 개발자의 관심사 중 하나인 변경의 영향을 보고했습니다. 나중에 Bogart et al. [6]은 개발자들이 종종 프로젝트의 종속성에 대한 잠재적으로 중요한 변경을 인식하는 것이 어렵다는 것을 알게 되며, 종속성에 대해 능동적으로 행동하기보다는 종속성이 중단되기를 기다리는 것을 선호한다고 관찰했습니다. 이후 연구[7]에서 주요 변경 사항은 개발자가 프로젝트 종속성을 업데이트하지 못하게 하는 주요 요인입니다. 또한 작성자는 개발자가 회사 정책에서 권장하더라도 프로젝트의 종속성을 업데이트하지 않는 경우가 있음을 관찰했습니다. 그러나 연구에서는 종속성으로 인한 기능 문제의 영향만 고려했으며 보안 문제의 영향은 고려하지 않았습니다.
Kulaet al. [25]는 우리가 알고 있는 종속성 업데이트 가능성에 대한 보안 권고의 영향을 연구한 유일한 논문입니다. 저자는 Github의 FOSS 프로젝트에 대한 보안 권고와 종속성 업데이트 사이의 상관 관계를 찾지 못했습니다. 개발자에 대한 일화적인 설문조사에 따르면 일부는 보안 권고 및 기존 보안 수정 사항을 인식하지 못했습니다. 그러나 저자는 프로젝트의 종속성을 업데이트하지 않은 FOSS 개발자만을 대상으로 했기 때문에 보고된 결과를 모든 개발자(예: 엔터프라이즈 개발자)에게 적용하면 일반화되지 않을 수 있습니다. 또한 이 연구는 심층적인 정성 분석(예: 코딩 없음, 이메일 응답에서 일부 인용만 게시)을 보고하지 않았습니다. 더욱이, Pashchenko et al.의 최근 연구. [33]은 작성자가 테스트 목적으로만 사용되는 취약한 종속성을 고려했기 때문에 [25]에 제시된 결과가 오탐의 영향을 받을 수 있다고 제안했습니다.
요약: 현재의 정성적 종속성 연구에 따르면 종속성 문제가 개발자의 결정에 영향을 미칠 수 있지만 연구는 주로 기능 문제에 중점을 두고 있으므로 보안 문제가 새로운 종속성 선택에 대한 개발자의 결정에 영향을 미치는지 여부에 대한 제한된 통찰력을 제공합니다. 소프트웨어 프로젝트에 포함(RQ1), 추가 관리(RQ2), 사용 가능한 종속성의 고정 버전이 없는 경우 개발자가 버그 및 취약성을 완화하는 방법(RQ4).
3.2 Technologies/tools for automating the software development process.
여러 논문에서 개발자가 소프트웨어 프로젝트의 자체 코드에서 기능과 보안 문제를 모두 식별할 수 있도록 하는 정적 분석 도구의 채택을 연구했습니다. 예를 들어, Vassallo et al. [43]은 정적 분석 도구 선택에 대한 개발 컨텍스트의 영향을 조사했습니다. 도구는 로컬 환경, 코드 검토 및 지속적인 통합의 세 가지 기본 개발 컨텍스트에서 채택됩니다. 그러나 Johnson et al. [21]은 팀워크 또는 협업에 대한 지원 부족 또는 취약, 많은 수의 오탐지 및 낮은 수준의 경고가 개발자의 채택을 가로막는 주요 장벽임을 확인했습니다. 이러한 연구는 개발자가 자동화된 도구를 사용하는 동안 직면하는 몇 가지 문제를 명확히 하지만 실제로 코드를 분석하지 않는 종속성 분석 도구를 사용하는 개발자의 인식에는 적용되지 않을 수 있습니다.
Mirhosseini와 Parnin[31]은 개발자가 종속성 분석 도구를 사용하는 방법을 분석한 유일한 연구입니다. 저자들은 자동화된 풀 리퀘스트가 개발자의 의존성을 업데이트하도록 장려하는지 여부를 정량적으로 연구했습니다. 자동으로 생성된 풀 리퀘스트 또는 배지를 사용하는 프로젝트는 의존성을 더 자주 업데이트했지만 개발자는 잠재적인 문제로 인해 그러한 풀 리퀘스트의 거의 3분의 2를 무시했습니다. 변경 사항을 깨고 있습니다. 연구에서 기능적 측면을 고려했기 때문에 보안이 자동화된 알림에 대한 개발자의 반응을 변경할 수 있는지 여부는 알 수 없습니다. 이 연구는 종속성 관리 도구로 greenkeeper.io를 사용한 JavaScript 개발자에 초점을 맞추었기 때문에 그 결과는 다른 종속성 관리 도구에 적용되지 않을 수 있습니다.
요약: 소프트웨어 엔지니어링 프로세스 자동화를 위한 기술 및 도구에 대한 정성적 연구는 개발자의 경험에 관한 흥미로운 관찰 결과를 보고하지만 종속성 분석 도구와 관련된 현재 연구는 주로 기능 측면에 초점을 맞추고 있으므로 개발자가 도구를 사용하는 방법에 대한 제한된 통찰력을 제공합니다. 소프트웨어 종속성(RQ3, RQ4)으로 인해 발생하는 보안 문제를 발견하고 완화합니다.
3.3 Information needs and decision making during software development
여러 연구[5, 16, 23, 25, 27, 34, 38, 39]에서 산업 종사자의 정보 요구와 의사 결정 전략을 설명합니다. 예를 들어 Unphon과 Dittrich[41]는 아키텍트나 핵심 개발자가 소프트웨어 아키텍처를 설계하고 수정하는 데 중심적인 역할을 한다는 것을 관찰했습니다. Panoet al. [32]는 네 가지 행위자(고객, 개발자, 팀 및 팀 리더), 성능 크기 및 자동화가 JavaScript 프레임워크의 선택을 유도한다고 보고했습니다. 다시 이 문서는 기업 개발자의 정보 요구와 행동 패턴을 포착하지만 의사 결정 선호 사항에 대한 보안 문제는 보고하지 않습니다.
Assal과 Chiasson[3]은 개발자와 소프트웨어 보안 프로세스 간의 상호작용을 연구하기 위해 소프트웨어 개발자를 대상으로 설문조사를 실시했습니다. 저자들은 구현 단계에 할당된 보안 노력이 코드 분석, 테스트 및 검토 단계보다 훨씬 더 높다는 것을 관찰했습니다. 이 논문은 자신의 코드에 대한 개발자 행동의 인간적 측면에 대한 좋은 통찰력을 제공하지만 소프트웨어 종속성(즉, 다른 사람의 코드)은 다루지 않습니다.
Linden[42]은 설문조사와 실험실 실습을 통해 다양한 개발 활동에서 개발자의 보안 인식을 연구했습니다. 저자는 개발자가 코드 작성 또는 외부 SDK 선택과 같은 코딩 활동에서 주로 보안을 고려한다는 것을 발견했습니다. 그러나 이 연구는 종속성을 사용하여 작업하는 동안 개발자의 추론에 대한 제한된 통찰력을 제공합니다. 또한, 결과는 Android 개발자만을 관찰하고 조사한 결과로 보고되었으므로 다른 개발 환경, 특히 NPM 또는 PyPI와 같은 중앙 종속성 관리 시스템이 있는 개발 환경에는 적용되지 않을 수 있습니다.
요약: 정보 요구에 대한 연구는 개발자의 의사 결정 전략에 대한 유용한 통찰력을 제공합니다. 그러나 기존 연구에서는 소프트웨어 종속성(RQ1 및 RQ2)으로 인해 발생하는 보안 문제가 있는 경우 개발자의 행동과 결정이 어떻게 변하는지 보여주지 않습니다.
4 METHODOLOGY
우리의 목표는 소프트웨어 종속성에 대한 개발자의 인식과 보안 문제가 결정에 미치는 영향을 연구하는 것입니다. 온라인 설문조사 또는 통제된 실험은 관심 있는 주장에 대한 조사관의 관점을 강요하므로 개발자의 의견이 흐려질 수 있습니다. 대신 반구조화된 인터뷰가 우리의 목표에 가장 적합합니다[46]. 개방적이기 때문에 면접관이 한 말의 결과로 면접 중에 새로운 아이디어가 떠오를 수 있으며 실제로 대부분의 선택된 연구에서 사용됩니다(표 7의 22개 연구 중 15개).
표 1은 섹션 3에서 논의된 논문의 참여자 수에 대한 기술 통계를 보여줍니다. 인터뷰 기반 연구에는 평균적으로 13명의 개발자가 고용되어 있습니다. 동시에 선택된 논문의 75%가 17개 미만의 인터뷰 결과를 보고합니다. 더욱이 연구는 일반적으로 단일 회사 또는 동일한 개발자 커뮤니티의 개발자 인터뷰 결과를 보고합니다. 개발자가 동일한 개발 전략과 접근 방식을 공유할 수 있기 때문에 이는 잠재적으로 약간의 편향을 유발할 수 있습니다.
4.1 Recruitment of participants
소프트웨어 개발자를 찾기 위한 소스로 지역 개발 커뮤니티를 참조했습니다. 우리는 이 그룹의 공개 채널을 사용하여 인터뷰 요청을 게시하고 참조인에게 연락했습니다. 그런 다음 우리는 눈덩이 샘플링 접근 방식[12]을 적용하여 응답자에게 자신이 관련된 친구 및 기타 개발 커뮤니티 내에서 전화를 배포하도록 요청하여 인터뷰 대상자의 수를 늘렸습니다. 눈덩이 접근 방식의 잠재적인 편견을 극복하기 위해 인터뷰에서, 우리는 각기 다른 회사와 종종 다른 국가를 대표하는 다양한 역할과 책임을 가진 개발자를 선택했습니다.
우리 연구에서 우리는 C/C++, Java, JavaScript 또는 Python과 같은 프로그래밍 언어 중 하나 이상을 사용하는 엔터프라이즈 개발자를 모집했습니다. 인터뷰 대상자는 최소 3년의 전문적인 업무 경험(6명의 개발자는 10년 이상)을 보유하고 있으며 일반 및 선임 개발자에서 팀 리더 및 CTO에 이르기까지 다양한 직책을 거쳤습니다. 일부 참가자는 내부/기업 개발에 참여하고 다른 참가자는 웹, 임베디드, 모바일 또는 데스크톱 응용 프로그램에서 작업합니다. 총 30명의 개발자3를 인터뷰했고 결국 9개국4에 위치한 25개 회사에 배포된 분석을 위해 25명을 유지했습니다. 표 2는 우리 샘플에서 인터뷰 대상자의 주요 인구 통계를 요약합니다.
이 표는 샘플의 인터뷰 대상자를 설명합니다. 우리는 인터뷰 중 의사소통된 직위, 전문적인 경험 및 기본 언어를 보고합니다. 위치별로 개발자 직장의 현재 국가를 지정합니다. 우리는 무료 및 오픈 소스 프로젝트(FOSS 프로젝트), 대기업(LE), 중소기업(SME), 사용자 그룹(UG)으로 회사를 클러스터링했습니다.
4.2 Interview process
1차 데이터를 수집하기 위해 약 30분 동안 인터뷰 세션을 가졌습니다. 우리는 우리 도시에 거주하는 인터뷰 대상자를 개인적으로 만났고 Skype 또는 Webex를 통해 다른 사람들과 원격 회의를 예약했습니다. 인터뷰에 응한 개발자는 고도로 숙련된 전문가이기 때문에 인터뷰 대상자에게 금전적 보상을 제공하지 않았습니다. 대신, 우리는 그들에게 흥미로운 주제에 대한 전문가 의견을 공유할 것을 제안했습니다. 동의 관리 및 데이터 처리를 위해 XXX 윤리 검토 위원회 절차를 따랐습니다5. 우리는 모든 인터뷰가 익명으로 보고될 것이며 개인이나 회사를 식별할 수 있는 데이터가 제공되지 않을 것이라고 설명했습니다. 개인 데이터가 수집되지 않았습니다.
우리는 연구를 위해 반 구조화 된 인터뷰 유형을 채택했습니다.개발자가 흐름을 정의할 수 있도록 질문을 구성했습니다.
즉, "그랜드 투어 인터뷰" 원칙을 따랐습니다. ple [17]. 그럼에도 불구하고 우리는 모든 인터뷰에 다음 부분이 포함되었는지 확인했습니다.
(반드시 그 순서는 아님):
- 서론 - 면접관이 연구의 맥락과 동기를 설명합니다.
- 개발자의 자기 소개 - 개발자(D)는 자신의 전문적인 경험과 현재 활동의 맥락을 제시합니다.
- 새로운 종속성 선택 - D는 소프트웨어 프로젝트에 새로운 종속성을 선택하고 포함하는 방법을 설명합니다.
- 종속성 업데이트 - D는 프로젝트에서 종속성을 업데이트하는 동기와 통찰력, 즉 업데이트하기에 적절한 시기, 종속성을 업데이트하는 빈도, 종속성 업데이트 프로세스에 관한 루틴이나 규정이 있는지 설명합니다. 그녀의 회사에서;
- 종속성 분석을 위한 일부 자동화 도구 사용 - D는 프로젝트에서 종속성 분석 프로세스를 용이하게 하는 자동 도구(사용되는 경우)를 설명하고 이 도구를 개발 프로세스에 통합하는 것에 대한 일반적인 세부 정보를 제공합니다.
- 종속성 문제 완화 - D는 종속성 문제(예: 버그 또는 취약성)를 해결하는 방법을 설명합니다.
- 종속성 관리에 관한 기타 일반적인 의견 - 여기에는 D가 종속성 관리 프로세스, 특히 소프트웨어 종속성으로 인해 발생하는 보안 문제에 대해 제공할 수 있는 몇 가지 일반적인 인식, 의견 또는 권장 사항이 포함됩니다.
각 인터뷰 세션에는 두 명의 면접관이 있었습니다. 각 면접관은 위에서 언급한 면접 부분의 목록을 가지고 있었고 논의한 대로 주관적으로 계산한 경우 해당 부분을 지웠습니다. 모든 부분이 교차되자마자 인터뷰가 끝났다.
각 인터뷰는 녹음 및 전사되었습니다. 녹취록은 익명으로 처리되었으며 확인을 위해 개발자에게 다시 전송되었습니다7. 녹음은 인터뷰 대상자를 식별할 수 있는 가능성을 보존하기 위해 파기되었습니다.
4.3 Interview coding and analysis
인터뷰를 분석하기 위해 우리는 응용 주제 분석을 채택했습니다[14]. 그림 1은 우리의 접근 방식을 요약한 것입니다. 이는 코드, 개념 및 코드 그룹의 체계적인 생성 및 반복적인 개념화를 통해 데이터가 분석에서 관련성을 얻는 출현의 원리를 따릅니다[13]. 데이터를 분석하고 관리 가능한 조각(코드)으로 나누고 유사점과 차이점을 비교합니다. 유사한 개념은 동일한 개념 제목(코드 그룹)으로 그룹화됩니다. 코드 그룹은 속성과 차원으로 구성되며, 마지막으로 분석의 구조를 제공한다[40].
분석의 첫 번째 단계(오픈 코딩)는 각 인터뷰 대상자 성적표에서 중요한 요점 진술을 수집하는 것으로 구성됩니다. 요점을 몇 단어로 요약한 코드가 각 요점 설명에 할당됩니다. 인터뷰 대상자 번호는 1번부터 25번까지입니다. 두 명의 연구원이 개별적으로 Saldaña[37]가 기술한 "반복적 프로세스"를 따라 전사된 인터뷰를 코딩했습니다. 그런 다음 그들은 결과 코드를 함께 살펴보고 예비 코딩 프로세스에 참여하지 않은 세 번째 연구원이 검토한 공통 코드 구조에 동의했습니다. 그래서 각 반복 후에 우리는 세 명의 연구원이 코드와 코드 그룹에 대해 완전히 동의했습니다. 결과 코드를 검토할 때마다 보고된 관찰[30], 즉 인터뷰 대상자가 동일한 개념에 대해 논의하는지 여부도 확인했습니다. 포화 상태에 도달했다고 결론지은 후 관찰의 안정성을 제어하기 위해 추가 개발자를 인터뷰했습니다(그림 1의 추가 확인 단계).
10번의 인터뷰를 마치자마자 코딩 프로세스를 시작했습니다. 처음에는 345개의 견적을 만들고 138개의 코드를 할당했습니다. 처음 6번의 반복 동안 우리는 가까운 주제에 대한 인용문과 병합 코드를 살펴봄으로써 인용문과 코드를 모두 통합했습니다. 그 결과 28개의 코드가 할당된 151개의 견적이 생성되었습니다. 다음 단계에서 우리는 15개의 인터뷰를 더 추가하여 인용 수를 크게 늘렸습니다(11번째 반복에서 533 인용). 추가하는 과정에서 관련 없는 코드(Scala)9가 하나 있다는 것을 알고 삭제했습니다. 따라서 10번째 반복에는 27개의 코드가 있었습니다. 그런 다음 개발자 역할(SME, LE, FOSS 또는 UG 개발자)에 대한 인용문과 코드를 추가하여 11번째 반복에서 31개의 코드와 574개의 인용문이 생성되었습니다. 코딩 프로세스의 마지막 단계에서 인터뷰 프로세스 파트에 해당하는 코드를 추가했습니다. 따라서 우리는 개발자 역할에 해당하는 4개의 코드, 인터뷰 프로세스 부분에 대한 6개의 코드, 829개의 인터뷰 인용문에 할당된 개발자 답변에 대한 27개의 코드로 끝났습니다.
우리의 관찰과 의미를 검증하기 위해 우리는 이 연구의 한 페이지 요약과 논문의 전체 버전을 인터뷰 대상자와 공유했습니다. 결과가 예상과 일치하는지 검증하도록 요청했습니다(그림 1의 마지막 단계).
4.4 Final Code Book
개발자 인터뷰를 분석하기 위해 대화 주제에 태그를 지정하는 다음 코드 그룹을 소개합니다.
- 종속성 코드 그룹은 대화의 일부가 예를 들어 소프트웨어 프로젝트의 소유 코드가 아니라 소프트웨어 종속성에만 해당됨을 나타냅니다.
- 언어 코드 그룹은 일반적인 소프트웨어 엔지니어링 프로세스와 관련된 일반적인 문제에 대한 논의보다는 특정 프로그래밍 언어(예: Java 대 Python)에 특정한 대화에 레이블을 지정합니다. 프로그래밍 언어(C/C++, Java, JS, Python)마다 다른 코드가 사용됩니다. 또한 대화에서 유사한 주제를 클러스터링하고 다음과 같이 해당 코드 그룹에 할당합니다.
- 태도 코드 그룹은 개발자가 보고한 사실에 대한 정성적 평가를 캡처합니다. 예를 들어, 개발자는 종속성 관리의 특정 단계와 관련하여 좋아하는 것, 싫어하는 것 또는 권장 사항을 표현합니다.
- 컨텍스트 코드 그룹은 문제가 기능 또는 보안과 관련이 있는지 여부와 같이 보고된 문제에 대한 배경 정보를 캡처합니다.
- 문제 코드 그룹에는 버그나 주요 변경 사항과 같은 기능 결함 또는 약점에 대한 토론이 포함됩니다.
- 작업 코드 그룹은 프로젝트 자체 코드 또는 해당 종속성의 특정 수정 사항을 캡처합니다. 예를 들어, 대화 조각은 종속성 관리 또는 종속성 유지 관리에 대해 설명합니다.
- 프로세스 코드 그룹은 개발자가 따르는 확립된 개발 관행의 존재를 포착합니다. 예를 들어, 대화 조각은 개발자 팀이 프로젝트의 종속성 관리를 자동화하는 방법을 설명합니다.
표 3은 우리 연구의 결과 코드 목록을 요약하고 그림 2는 코드 발생 횟수를 보여줍니다. 동일한 문장에 여러 코드로 레이블이 지정될 수 있습니다.
한 달에 한 번 고객에게 알리는 계약이 있습니다. 우리가 오늘 취약점을 발견했다면 클라이언트는 한 달 안에 그것에 대해 알게 될 것입니다. 물론 취약점이 심각하지 않은 경우입니다. 중요한 경우 정보를 수집하는 즉시 고객에게 알립니다.(#5)
종속성 관리, 파이썬(개발자가 파이썬에 대해 이야기하는 것처럼), 요구 사항, 보안과 같은 코드와 연결되어 있습니다.
5 FINDINGS
우리는 개발 커뮤니티 내에서 확립된 관행이 우리의 결과에 영향을 미치는지 확인10했습니다. 언어별 코드 배포를 고려할 때 Java, JavaScript 및 Python 개발자가 종속성 관리에 대해 유사한 태도를 공유한다는 것을 관찰했습니다. 가장 빈번한 코드는 관리, 보안 및 버그입니다. C/C++ 개발자의 대부분의 우려는 이러한 코드와 코드 싫어함의 동시 발생이었습니다. 따라서 아래에서는 프로그래밍 언어로 구분하지 않고 결과를 제시합니다.
5.1 RQ1: rationale for selection
5.1 RQ1: 선택의 근거
프로젝트에 대한 새로운 종속성을 선택하는 개발자의 근거와 보안 측면이 선택에 영향을 미치는지 여부를 이해하기 위해 코드 관리로 표시되는 동시에 정보를 찾는 개발자의 답변을 연구했습니다.
관찰 1: 보안이 회사 정책에 따라 시행되는 경우 선택 대상으로 고려됩니다. 일부 회사는 자체 개발하거나 사전 승인된 FOSS 라이브러리를 가져오기 때문에 개발자가 프로젝트에서 사용하도록 권장하거나 때로는 제한을 받기도 합니다.
인터뷰에 응한 개발자 중 3명(#5, #10, #28)은 소프트웨어 종속성을 선택할 때 보안을 고려한다고 직접 커뮤니케이션했습니다. 그러나 그들에게 이것은 회사의 정책에 따라 강제되었습니다. #10은 다음을 보장하는 내부 종속성 평가 도구에서 승인한 종속성만 사용해야 합니다.
라이브러리는 안전하지만 #5는 라이브러리가 프로젝트의 핵심에 포함될 계획인 경우 라이브러리의 보안 기록을 확인합니다.
개발자 #10, #12 및 #13은 회사에 사전 승인된 FOSS 및 자체 개발 라이브러리가 있다고 언급했습니다. 이러한 라이브러리 및 해당 종속성은 보안 문제 및 기능 버그의 존재 여부를 확인하므로 FOSS 대안과 비교하여 더 높은 우선 순위를 사용합니다.
[사전 승인된 라이브러리]를 적극적으로 사용하려고 합니다. 이것은 높이 평가되며 때로는 코드 재사용으로 인해 강제되기도 합니다. [...] (#13)
토론.Derr et al. [11]은 Android 개발자가 새로운 종속성을 선택하는 데 가장 덜 중요한 기준으로 보안을 고려한다고 보고한 반면, 몇몇 최근 논문에서는 보안을 고려하려는 개발자의 결정에 회사 정책이 미치는 영향을 강조합니다. 초기 종속성 연구[7, 9]에 따르면 회사 정책은 개발자가 보안을 고려하도록 권장할 수 있지만 실제로 이러한 정책이 항상 준수되는 것은 아닙니다. 보다 최근의 연구(예: [3, 42])에서는 보안 고려 사항에 관한 개발자의 결정에 회사 정책이 더 큰 영향을 미치는 것으로 나타났지만 이러한 연구는 종속성 선택 프로세스에 대한 회사 정책의 영향에 대한 제한된 통찰력을 제공합니다. 따라서 우리의 관찰은 회사 보안 정책이 소프트웨어 종속성에 관한 개발자의 결정에도 영향을 미치는지 명확히 합니다.
관찰 2: 개발자는 대부분 라이브러리의 커뮤니티 지원에 의존합니다. 잘 지원되는 라이브러리에서 취약점이나 버그가 발견되면 수정 사항이 빠르게 나타나고 채택하기 쉽고 종속 라이브러리를 손상시키지 않습니다.
인터뷰에 응한 다른 개발자들은 기능과 보안 문제를 모두 해결하는 데 커뮤니티를 활용할 수 있기 때문에 고려 중인 라이브러리의 커뮤니티 지원에 의존했습니다. 잘 지원되는 라이브러리에서 취약점이 발견되는 경우 신속하게 수정되고 보안 수정 사항이 수정됩니다. 종속 프로젝트를 중단하지 않기 때문에 일반적으로 채택하기 쉽습니다.
나는 빠른 google을 하고 많은 사람들에게 가장 잘 맞는 것을 선택합니다[...] 만약 버그가 있다면, 그것은
정식 패키지를 사용하고 [커뮤니티에 지원을 요청] (#15)
토론. Android 개발자에 대한 이전 연구[11, 21, 42]에서는 개발자가 커뮤니티 지원과 중앙 패키지 관리자가 부족하다고 보고했습니다. 우리는 확립된 중앙 패키지 관리자(Maven, NPM, PyPI)의 맥락에서 작업하는 개발자의 생태계를 연구하여 격차를 메웁니다. 이전 논문[7, 16]은 개발자가 기능적 관점에서 더 안정적이기 때문에 프로젝트에 포함할 인기 있고 잘 지원되는 라이브러리를 선호한다고 제안했습니다. 따라서 개발자가 커뮤니티 지원을 다음과 같이 인식한다는 증거를 제공하여 이러한 관찰에 추가합니다.
도서관의 '보증'이 됩니다.
관찰 3: 종속성 선택은 종종 숙련된 개발자나 소프트웨어 설계자에게 할당됩니다.
새로운 종속성을 선택하는 작업은 종종 소프트웨어 설계자(#10, #14, #17) 또는 "경험이 있는 사람"(#12)에게 할당됩니다.
가장 어려운 경우는 어떤 종속성이 있어야 하는지를 결정하는 것입니다.
사용, 종속성을 사용하는 방법 또는 일반적인 디자인
프로젝트의 구조. 소프트웨어 구조를 설계하는 작업을 소프트웨어 설계자에게 할당하는 이유는 경험이 많기 때문입니다. 개발자가 실제로 작업하기 전에 프로젝트를 확인해야 합니다. (#17)
Discussion.Pano et al. [32]는 개발자, 고객, 팀 및 팀 리더의 조합이 종종 개발 기술/프레임워크의 선택으로 이어진다고 보고했습니다. 이러한 관점에서 우리는 대형 SME 및 LE에서 종속성 선택(즉, 사전 선택된 프레임워크 내에서 사용할 특정 라이브러리)이 종종
숙련된 개발자 또는 소프트웨어 설계자에게 할당됩니다.
관찰 4: 종속성 선택의 경우 개발자는 주로 라이브러리의 보안보다는 라이브러리의 기능 지원에 중점을 둡니다.
인터뷰에 응한 개발자들은 프로젝트를 위한 새로운 소프트웨어 종속성을 선택하는 동안 보안보다 기능 측면을 두 번 더 자주 언급했습니다. 7명의 개발자 인터뷰에서 보안 및 새로운 종속성 코드 선택.
관찰 5: 종속성 선택을 위해 개발자는 라이브러리 소스 코드의 하위 수준 세부 정보보다는 라이브러리에 대한 커뮤니티 지원을 보여주는 상위 수준 정보를 참조합니다.
우리가 새로운 종속성 선택에 대해 질문했을 때 개발자들은 종종 새로운 종속성에 대한 추가 정보를 얻기 위해 타사 리소스에 의존한다고 보고했습니다. ) 프로젝트에 새로운 종속성을 포함하기 전에 참조하는 추가 정보 소스를 공유했습니다.
25명의 개발자 중 14명(#1, #4, #5, #6, #8, #9, #13, #15, #17, #19, #22, #23, #24, #25) Github는 특정 라이브러리 뒤에 강력한 커뮤니티가 있는지 여부를 이해하고 필요한 경우 라이브러리 코드에 대한 추가 세부 정보를 얻을 수 있기 때문에 Github.com을 기본 정보 소스로 사용합니다. 높은 수준의 정보로 인터뷰 대상자는 별 수(#1, #4, #6, #9, #22, #23), 프로젝트 기여자(#4, #15, #23), 및 도서관 이용자(#4, #5, #9, #15, #22, #25). 또한 개발자들은 프로젝트의 코드 스타일(#5, #8, #9, #22), 커밋 빈도(#4, #5, #8, #9, #17, #23, # 24), 해결된 문제 수(#5, #9, #17), 아직 미해결 상태(#17), 미해결 문제가 수정되는 속도(#4, #5, #17).
라이브러리에 열려 있는 수천 개의 문제가 있는 경우 주의해야 합니다. [한 번] 통합되면 동일한 문제가 발생할 수 있습니다. (#9)
개발자들이 언급한 추가 정보 출처는 Google(#4, #6, #15, #16, #25), Maven Central(#4, #12, #17, #19)과 같은 종속성 저장소, Node.js입니다. js 또는 PyPI(#9, #24) 및 StackOverflow(#22). 개발자는 특정 작업을 해결하는 가장 인기 있는 종속성을 찾기 위해 이러한 소스를 참조했습니다.
가장 많이 참조된 출처와 정보 유형에 따르면 인터뷰에 응한 개발자는 보안 측면에 거의 관심을 기울이지 않고(이 관찰은 불쾌할 수 있음) 대신 라이브러리에 대한 우수한 커뮤니티 지원을 찾습니다. 라이브러리에 빠른 보안 수정 사항이 있지만 수정 사항이 있는 경우 기능 문제가 오래 지속되면 그러한 라이브러리는 선택되지 않을 것입니다.
토론. 새로운 종속성을 선택하면서 개발자가 참조하는 정보 소스에 대한 기존 관찰(예: [7, 9, 11])을 보완하고 보안 관점에서 특정 정보 소스가 참조되는 이유에 대한 구체적인 통찰력을 제공합니다.
관찰 6: 법적 문제를 피하기 위해 엔터프라이즈 개발자는 새 프로젝트 종속성을 선택하는 동안 소프트웨어 라이선스를 확인합니다.
보안 및 기능 외에도 우리가 다룬 모든 조직 유형의 개발자는 독점 소프트웨어 프로젝트의 일부로 사용하는 라이선스 문제가 있기 때문에 소프트웨어 종속성을 선택할 때 주의해야 한다고 지정했습니다. FOSS(#13, #24) , 중소기업(#14, #24), LE(#3, #10, #13), UG(#2)
[...] 일부 소프트웨어를 판매하고 소프트웨어 내부에 GPLv3과 같은 제한된 라이선스가 있는 경우 라이브러리 소유자가 다음을 발견할 수 있기 때문에 많은 법적 문제가 있을 수 있습니다.
많은 법적 문제가 있을 수 있습니다. (#삼)
토론. FOSS 생태계의 현재 질적 연구[16, 42]는 소프트웨어 종속성을 선택하기 위한 개발자의 결정에 대한 법적 문제의 영향에 대한 제한된 통찰력을 제공했습니다. 예를 들어, Linden et al. [42]는 실험실 작업을 위해 모집된 개별 개발자가 타사 소프트웨어 사용 이면의 법적 문제에 대한 이해가 제한적이며(이해하는 데 인내심이 거의 없다고) 보고했습니다. 대조적으로, 우리는 우리가 다룬 각 조직 유형(FOSS, SME, LE, UG)에 속한 개발자가 종속성을 프로젝트에 포함하기 전에 종속성 라이선스를 고려한다고 보고한 것을 관찰했습니다.
5.2 RQ2: motivations for (not) updating
5.2 RQ2: 업데이트(안)에 대한 동기
이 연구 질문에 답하기 위해 종속성 관리 프로세스의 특수성을 살펴보았습니다. 보다 구체적으로, 태도 코드 그룹의 코드로 레이블이 지정된 대화 조각을 고려했습니다(표 4).
관찰 7: 일반적으로 개발자는 종속성 관리 프로세스에 대해 혼합된 인식을 가지고 있는 반면 강하게 부정적인 태도와 매우 긍정적인 태도를 가진 개발자는 거의 없습니다.
개발자들은 종속성 관리 프로세스에 대해 서로 다른 인식을 표현했습니다. 그들은 부정적인 측면(22명의 개발자 인터뷰에서 86개의 코드 싫어함 및 관리의 동시 발생)을 언급했을 뿐만 아니라 종속성 관리에 대한 긍정적인 태도를 표명했습니다(44개의 동시 발생 18 개발자의 인터뷰에서 코드와 같은 관리). 6명의 개발자는 문제가 있는 측면만 언급했고, 2명은 긍정적인 태도만 보고했으며, 16명의 개발자는 종속성 관리 프로세스에 대해 혼합된 인식을 표현했습니다(즉, 인터뷰에서 관리 코드와 싫어요 및 좋아하는 코드의 동시 발생이 포함됨).
예, AngularJS [...]에서 Angular2로 전환하는 것이 정말 어려웠습니다. 그러나 그들은 훌륭한 일을 해냈기 때문에 Angular2, 4, 5, 6, [...] 같은 다른 모든 업데이트는 정말 매끄럽습니다. 미친 짓을 많이 할 필요는 없습니다. (#21)
토론. 몇몇 이전 연구[6, 7, 9, 25, 31]에서는 개발자가 종속성 관리 프로세스에 대해 주로 부정적인 태도를 가지고 있다고 보고했지만 엔터프라이즈 개발자는 혼합된 인식을 가지고 있는 반면 일부 개발자는 긍정적인 태도만 표현한 것으로 나타났습니다.
관찰 8: 개발자가 프로젝트의 종속성을 업데이트하면 취약점에 주의를 기울입니다.
샘플에서 개발자에게 가장 중요하고 논의된 문제는 버그였습니다(22명의 개발자 인터뷰에서 84번 발생). 개발자들은 버그에 대해 이야기할 때 종종 취약점에 대해 논의했습니다(코드 버그 및 보안의 동시 발생 61건).
관찰 9: 개발자는 보안 관련 수정 사항을 채택하기 쉬운 것으로 인식합니다. 널리 사용되고 잘 지원되는 라이브러리의 경우 이러한 수정 사항이 빠르게 나타나고 종속 프로젝트를 중단하지 않기 때문입니다.
개발자는 취약점을 거의 도입하지 않고 신속하게 수정하는 잘 알려진 안정적인 라이브러리(#5, #6, #16 및 #17)만 사용하기 때문에 종속성 취약점 수정에 대해 부정적인 우려를 하지 않습니다. 또는 해당 프로젝트가 보안에 중요하지 않습니다. 즉, 내부 목적으로만 사용되므로 종속성에 취약점이 나타나더라도 악용되지 않습니다(#3, #4, #9 및 #24). 또한 고정 종속성 버전을 채택해도 일반적으로 종속 프로젝트(#1, #4, #11 및 #14)가 중단되지 않습니다. 토론. 개발자들은 종속성을 관리하기 어렵거나 공급업체로부터 업데이트를 제공할 때 지원이 부족하다고 느꼈기 때문에 종속성에 대해 덜 능동적인 것으로 보고되었습니다[6]. 그러나 우리는 소프트웨어 종속성의 보안 수정에 대한 개발자의 일반적으로 긍정적인 태도를 관찰합니다.
잘 지원되는 종속성은 빠르게 나타나고 채택해도 종속 프로젝트가 중단되지 않습니다.
관찰 10: 개발자는 새로운 종속성 버전에 의해 도입된 주요 변경 사항(전이적 종속성에 숨겨져 있을 수 있음)에 대처할 리소스가 부족하기 때문에 프로젝트의 종속성 업데이트를 피하는 경향이 있습니다.
많은 인터뷰 대상자들은 일반적으로 프로젝트의 종속성 업데이트를 피하려고 한다고 보고했습니다. 14명의 개발자(#1, #4, #7, #8, #9, #10, #11, #12, #14, #15, #16, #17, #18, #23)는 11명의 개발자(#4, #7, #8, #9, #12, #13, #14, #16, #17, #19, #23)는 적절한 종속성 관리를 수행할 리소스가 충분하지 않다고 언급했습니다. 업데이트로 인해 주요 변경 사항이 발생할 수 있으므로 프로젝트의 종속성 업데이트를 피합니다.
우리 프로젝트는 거대합니다. 우리는 한 번 시도했고 1000 테스트가 다운되었습니다. 그것을 고치기 위해[...] 우리는 그럴 시간이 없습니다. 그리하여 모든 것이 얼어붙었다. (#8)
8명의 개발자(#1, #2, #3, #7, #13, #14, #17, #23)는 제어하기 어려운 전이 종속성이 많아 종속성 관리에 문제가 있다고 말했습니다. 토론. 종속성에 대한 개발자 인식에 대한 이전 연구[7, 11, 31]는 개발자가 프로젝트의 종속성을 업데이트하지 못하게 하는 주요 요인으로 주요 변경 사항을 보고했습니다. 우리의 발견은 이러한 연구를 보완하고 또한 프로젝트 안정성이 개발자에게 가장 높은 우선 순위임을 제안합니다. 즉, 개발자가 이 업데이트에 주요 변경 사항이 없다고 확신하지 않는 한 보안상의 이유로 종속성을 업데이트하지 않습니다. 또한 우리가 관찰한 바에 따르면 많은 수의 전이적 종속성에 대한 제어가 부족하면 종속성을 관리하고 업데이트하는 데 상당한 부담이 발생합니다. 이는 기술적 부채, 성능상의 이유 또는 버그 수정 외에도 종속성을 업데이트하지 않는 주요 이유 중 하나일 수 있습니다[11].
관찰 11: 회사 정책은 모든 새 버전을 채택하거나 모든 업데이트를 무시하는 두 가지로 필드를 분할하여 소프트웨어 종속성 업데이트에 대한 개발자의 결정에 상당한 영향을 미칩니다.
개발자 #7과 #19는 확립된 관행과 회사 사고 방식이 개발자로 하여금 서로 다른 종속성 관리 전략을 따르도록 할 수 있다고 말했습니다. 예를 들어 개발자 #7, #15, #19, #21은 프로젝트의 종속성을 최신 상태로 유지하고 새 종속성 버전이 나타날 때마다 "작은" 업데이트를 수행한다고 말했습니다. 업데이트 프로세스는 "매우 매끄럽게" 보입니다.
[회사 이름]에서 종속성 업데이트에 직면했습니다. 그리고 거기에 그런
작업은 한 달에 두 번 정도 나타났습니다. (#19)
반면에 #7, #8, #12, #15, #19 개발자는 위험을 회피하는 사고방식과 적절한 동기 부여 부족으로 인해 소프트웨어 종속성 업데이트를 최대한 피하려고 한다고 언급했습니다. 소프트웨어 종속성 업데이트(새롭다는 것이 버그가 없다는 의미는 아님): 문제가 있는 측면을 표현하지 않았지만 개발자 #8, #12, #19는 회사 정책이 제안하기 때문에 프로젝트의 종속성을 업데이트하지 않는다고 보고했습니다. 종속성의 버전을 변경하지 않은 상태로 유지합니다.
나는 이 일을 하면서 대부분의 사람들이 라이브러리 업데이트가 필요한 이유와 코드를 리팩토링해야 하는 이유를 이해하지 못하는 것에 직면했습니다. 모든 것이 작동하면 만지지 마십시오. 가장 필요합니까? 그리고 내가 모든 것을 혼자 해결하기 시작하면 모두를 설득하는 데 미친 사람이 될 것입니다. 사실 저는 코드 품질을 조금 높이려고 했을 때 그다지 좋지 않은 경험을 했습니다. 그리고 사람들은 불평하기 시작했습니다. 왜 그것을 만졌습니까? (#8)
토론. 개발자는 라이브러리가 의도한 대로 작동할 때 항상 업데이트하도록 권장되지 않는 것으로 보고되었습니다[11, 31], 업데이트에 약간의 개선만 포함되어 있거나[3], 사용 가능한 개발 리소스가 충분하지 않습니다[25]. 이전 연구와 대조적으로 우리는 몇몇 엔터프라이즈 개발자가 반대 접근 방식을 가지고 있음을 관찰했습니다. 즉, 종속성의 새 버전이 나타나는 즉시 프로젝트의 종속성을 업데이트합니다. 인터뷰 대상자들은 이러한 종속성 관리 관행의 변화를 위한 핵심 요소로 회사 정책을 제안합니다.
5.3 RQ3: automation of dependency management
RQ3에 답하기 위해 프로세스 코드 그룹의 코드 중 하나로 표시된 개발자의 답변을 살펴보았습니다.
관찰 12: 종속성 분석 도구(사용되는 경우)는 종속성 내에서 발생하는 문제 식별에 적용되므로 개발자는 결과를 평가하여 새 종속성 버전을 채택할지 여부를 결정할 수 있습니다. 종속성 업데이트 자체는 수동으로 수행됩니다.
종속성 관리(표 5 참조)에서 개발자는 종종 회사 내에서 설정된 상황 정보를 참조했습니다. 코드 관리 및 워크플로는 16명의 개발자(#3, #5, #7, # 9, #10, #12–14, #18–25).
개발자 #3, #5, #7, #10은 프로젝트의 종속성 내에서 가능한 문제를 식별하기 위해 일상 업무에 종속성 분석 도구를 적용한다고 보고했습니다(26개의 코드 종속성 도구 및 관리 ). 워크플로와 통합된 자동 종속성 검색 도구가 있으며 생성된 문제를 수동으로 확인해야 합니다. 종속성을 업데이트하기로 결정한 경우 개발자 #3, #7, #9, #17 및 #18은 새 버전을 사용하도록 프로젝트를 수동으로 구성한 다음 프로젝트가 올바르게 작동하는지 수동으로 테스트하는 것을 선호합니다.
요청을 추가하고 "이 라이브러리를 갖고 싶습니다"라고 말합니다. 이에 대한 프로세스가 있으며 누군가 이를 조사하고 [종속성 도구]를 실행하면 자동 보고서를 받게 됩니다. 그래서 [라이브러리]가 지워지거나 하지 않을 것입니다. (#10) 토론. 여러 연구[6, 9, 20]에서는 개발자가 프로젝트에 영향을 미치는 보안 문제에 대한 인식 부족으로 인해 종속성을 업데이트하지 않는다고 보고했습니다. 여기에는 몇 가지 이유가 있습니다.
적절한 보안 지식의 부재, 보안 평가 계획 및 적절한 도구의 부재[3]. 그러나 연구에서는 종속성 분석 도구의 역할을 조사하지 않았습니다. 우리는 엔터프라이즈 개발자가 종속성 분석 도구의 존재를 알고 있고 (해당되는 경우) 수동 종속성 관리 작업을 계획하기 위한 지원 정보 소스로 사용하는 것을 관찰했습니다. 그러나 그들은 프로젝트의 종속성을 자동으로 업데이트하는 것과 같은 민감한 작업을 위한 도구에 의존하지 않습니다. 마지막 관찰은 Mirhosseini와 Parnin[31]이 보고한 발견을 일치시키고 보완합니다.
관찰 13: 개발자는 라이브러리가 사용하기에 안전하고(보안 배지) 성숙하며 전이 종속성을 너무 많이 가져오지 않음을 보여주는 상위 수준 메트릭을 도입할 것을 권장합니다.
새로운 종속성 선택을 용이하게 하기 위해 개발자 #6은 Github(또는 종속성 관리 시스템)에 특정 종속성의 사용이 안전한지 여부를 보여주는 배지를 사용할 것을 권장합니다. 특정 버전의 종속성에서 취약점을 확인하는 것 외에도 개발자 #16 및 #25는 종속성이 성숙한지(5.1 참조) 정의할 것을 제안하는 반면 개발자 #13은 새 종속성이 기술 스택을 늘리거나 도입하는지 확인하려고 합니다. 새로운 전이 종속성.
Discussion.Mirhosseini와 Parnin[31]은 개발자들이 자동화된 버그 수정 제안이 받아들여지도록 뒷받침하고 설명하는 몇 가지 주장을 보고 싶어한다고 보고했습니다. 또한 저자는 개발자가 종속성 변경에 대한 수동 알림(예: 배지)을 선호한다는 것을 발견했습니다. 우리는 소프트웨어 종속성에 대한 정보와 관련하여 유사한 개발자의 욕구를 관찰합니다. 개발자는 라이브러리를 채택해야 하는지 여부를 보여주는 상위 수준 메트릭(즉, 인수)을 원합니다.
관찰 14: 개발자는 종속성 분석 도구가 관련성이 없거나 우선 순위가 낮은 경고를 많이 생성한다고 생각합니다.
개발자 #9, #15 및 #22는 종속성 분석 도구를 시도했지만 관련되지 않은 경고의 수가 많기 때문에 작업 프로세스에 이 도구를 도입하지 않기로 결정했습니다.
나는 하나 [dep. 분석도구] 스팸성 경향이 있어 껐습니다. 예를 들어, 사소한 취약점을 보고했기 때문에 나는 그것들에 대해 짜증을 냈습니다. (#15)
관찰 15: 여러 개발자가 종속성 분석 도구를 시도했지만 소셜 채널을 통해 배포되는 취약점 수정 및 기능 개선에 대한 정보에 의존하기로 결정했습니다.
많은 개발자(#1, #2, #3, #7, #9, #10, #11, #17, #18)가 종속성을 수동으로 분석합니다. 5명의 개발자(#1, #2, #4, #18, #24)는 Twitter 또는 종속성 메일링 리스트와 같은 소셜 채널을 사용하여 발견된 문제 및 프로젝트 종속성의 새 버전에 대한 정보를 수신한다고 말했습니다. Discussion.Observation 14는 종속성 분석 도구가 소프트웨어 프로젝트의 자체 코드에서 보안 문제를 찾는 데 사용되는 정적 분석 도구(예: [21, 43])의 잘 알려진 약점을 공유한다고 제안합니다. 개발자. 따라서 그들은 도구를 포기하고 때로는 그것이 제공하는 정보가 소화하기에는 너무 많지만 사회적 지원을 찾는 것을 선호합니다[7].
관찰 16: 개발자는 관련 경고만 보고하고, 오프라인으로 작업하고, 회사 워크플로에 쉽게 통합하고, 취약한 종속성의 최신 버전과 초기 안전 버전을 모두 보고하는 종속성 분석 도구를 권장합니다.
종속성 분석 도구와 관련하여 개발자 #18은 분석된 프로젝트에 실제로 영향을 미치는 결과만 보고하는 도구를 제안합니다(가능하면 가양성 수 줄이기). 개발자 #9는 보안 도구가 오프라인으로 작동해야 한다고 제안합니다. 그렇지 않으면 분석된 프로젝트에 대한 일부 민감한 정보가 공개될 수 있기 때문입니다. 개발자 #19는 소프트웨어 종속성을 분석하기 위한 도구가 개발 파이프라인과 쉽게 통합되어야 한다고 제안하는 반면 개발자 #22는 식별된 취약한 종속성의 초기 및 최근 안전한 버전을 모두 보고하기를 원하므로 업데이트할 여러 버전을 고려할 가능성.
토론.Johnson et al. [21] 개발자는 워크플로를 방해하지 않고 자신의 코드에 대한 특정 결함을 무시할 수 있는 효율적인 방식으로 더 빠른 피드백을 제공하는 코드 분석 도구를 원한다고 보고했습니다. 종속성 분석 도구에 대한 유사한 요구 사항을 관찰합니다.
관찰 17: 개발자는 종속성 분석 도구를 정적(또는 동적) 분석 도구와 유사하다고 생각하고 이러한 도구를 통합하여 동시에 적용할 수 있도록 권장합니다.
개발자 #2, #3, #8, #9, #13은 종속성 분석 도구를 코드 분석 도구(즉, 정적 또는 동적 분석 도구)와 유사한 것으로 간주했습니다. 따라서 소프트웨어 개발 프로세스의 동일한 단계에 적용할 수 있습니다.
종속성에 대한 보안 평가는 코드 보안 평가의 일부이기 때문에 코드의 보안 평가와 거의 유사해야 합니다. (#삼)
개발자 #3과 #13은 코드 분석 도구(예: SonarQube)의 보고서를 종속성 분석 도구에서 생성된 경고로 보강할 것을 권장했습니다.
의존성 분석 결과를 SonarQube에 연결할 수 있을까요? 따라서 나중에 지속적 통합에서 이를 사용하고 지속적인 코드 분석을 수행할 수 있습니다. 이 있으면 멋질 것입니다. (#13)
토론. 우리는 개발 워크플로에 종속성 분석 도구의 통합을 논의하는 다른 관련 작업을 찾지 못했습니다. 엔터프라이즈 개발자는 종속성 분석 도구를 정적 분석 도구와 유사하게 통합적으로 인식하는 경우가 많기 때문에 빌드 또는 컴파일 시간과 같은 개발 프로세스 동안 도구를 동시에 적용할 수 있습니다[21, 43]. IDE[15] 또는 코드 리뷰[43]에 통합되었습니다.
5.4 RQ4: Mitigating unfixed vulnerabilities
RQ4에 답하기 위해 우리는 취약한 종속성의 최신 버전이 취약점에 대한 수정 사항이 없는 경우의 완화 방법을 설명하는 개발자의 답변을 조사했습니다(코드가 태그가 지정된 인터뷰 조각은 가용성 및 싫어요 수정).
관찰 18: 수정 사항이 없는 취약한 종속성을 발견하면 개발자는 먼저 이 취약성이 프로젝트에 영향을 미치는지 여부를 이해하려고 시도합니다. 수정에 상당한 노력이 필요한 경우 개발자는 취약성을 유지하기로 결정할 것입니다.
인터뷰 대상자 #1, #3, #7, #11, #23은 취약한 종속성의 고정 버전을 항상 찾을 수 있다고 말했지만 다른 사람들은 그러한 상황을 가능성 있고 문제가 있다고 생각했습니다.
수정 사항이 없는 취약한 종속성의 경우를 발견했을 때 개발자 #3, #5, #7, #14는 먼저 이 취약점이 프로젝트에 영향을 미치는지 평가합니다.
영향을 받는 기능. 취약한 종속성이 프로젝트에 영향을 미치지 않는 경우 개발자는 프로젝트를 변경하지 않고 그대로 두기로 결정할 수 있습니다(예: #16). 프로젝트가 영향을 받는 기능에 의존하지만 취약점 수정에 상당한 개발 노력이 필요하더라도 개발자 #1, #2, #12, #15는 취약점을 유지하는 것을 선호합니다.
모든 신청서를 다시 작성해야 하고 비용이 많이 든다면,
그러면 아마도 우리는 취약성을 유지하게 될 것입니다. (#2)
토론. 여러 개발자의 연구(예: [11, 25, 29])는 개발자가 이 작업의 절대적인 필요성을 이해하지 않는 한 종속성 변경을 피하려고 한다는 증거를 보고했습니다. 따라서 이 발견은 이러한 연구와 일치합니다. 개발자가 첫 번째 단계는 취약점이 프로젝트에 영향을 미치는지 이해하고 [16, 25] 취약점을 완화하는 데 필요한 노력을 추정하는 것이기 때문입니다.
관찰 19: 취약점이 프로젝트에 영향을 미치는 경우 일부 개발자는 영향을 받는 기능을 일시적으로 비활성화하고 "공식" 패치를 기다리기로 결정할 수 있습니다.
개발자 #2와 #12는 취약한 종속성의 영향을 받지 않은 이전 버전으로 롤백할 수 있다고 말했습니다.
개발자가 프로젝트 종속성을 수정하지 않고 보안 문제를 해결하기로 결정한 경우 다른 라이브러리 사용자 또는 유지 관리자가 제안한 솔루션(예: #4 및 #15)을 확인할 가능성이 높습니다. 유지 관리자가 문제에 대해 작업하고 있고 곧 수정 사항을 릴리스할 예정인 경우 개발자 #4, #17 및 #20은 취약점에 노출된 프로젝트 기능을 일시적으로 비활성화합니다.
[이미지] 라이브러리의 구성을 완전히 변경해야 했습니다.
특정 공격 벡터를 허용하지 않습니다. (#20)
토론.Bogart et el. [7] 개발자는 종속성에서 (기능) 버그를 처리하는 데 덜 적극적으로 행동한다는 것을 관찰했습니다. 때때로 개발자는 자신의 프로젝트에 대해 아무 것도 하지 않고 종속성의 고정 버전을 기다리기로 결정합니다[29]. 취약점 공개의 경우 개발자가 보다 능동적인 것으로 나타났습니다. 개발자는 프로젝트에 대한 취약점의 영향을 확인하고 영향을 받는 프로젝트 기능을 비활성화하여 즉각적인 솔루션을 제공합니다.
관찰 20: 숙련된 개발자는 종속성의 취약점을 수정하고 종속성 프로젝트에 기여합니다.
숙련된 개발자 #4, #7, #8, #13, #15는 보안 취약점을 스스로 수정하기로 결정할 수 있습니다. 개발자 #4, #8, #13, #15는 취약한 종속성의 내부 포크를 만들고 "공식" 취약점 수정이 릴리스될 때까지 유지하는 것을 선호한다고 말했지만 개발자 #7과 #13은 보고했습니다. 회사의 개발자가 실제로 발견된 보안 문제를 수정하고 FOSS 리포지토리에서 pull 요청을 열어 타사 프로젝트에 기여합니다.
이 취약점이 우리 작업에 심각한 영향을 미치고 이것이 오픈 소스 제품인 경우 수정하면 됩니다. 예를 들어 Github에만 있는 경우 수정하여 Pull Request를 생성합니다. 그리고 기여자 또는 유지 관리자에게 이 풀 요청을 마스터 브랜치에 병합하도록 요청합니다. 그리고 우리는 새로운 버전을 더 빨리 출시하도록 그들을 압박하고 있습니다. (#13)
토론. 최근 여러 논문[7, 16, 29]에서는 전문 지식에 따라 개발자가 일부 기능 문제를 해결하기 위해 종속성 프로젝트에 기여하기로 결정할 수 있다고 보고했습니다. 인터뷰에 응한 개발자들은 기능과 보안 수정 사항을 구별하고 보안 수정 사항에는 더 높은 전문성이 필요하다고 생각한다고 보고했습니다. 또한 숙련된 개발자가 보안 문제를 수정하여 종속성 프로젝트에 기여하는 것도 관찰했습니다.
관찰 21: 최후의 수단으로 개발자는 프로젝트의 취약한 종속성을 유사한 기능을 제공하는 다른 라이브러리로 대체할 수 있습니다.
소프트웨어 라이브러리 수정이 너무 복잡하고 라이브러리가 제대로 지원되지 않는 경우 개발자는 사용을 중지하고 다른 라이브러리(예: #3 및 #23)로 전환하기로 결정할 수 있습니다.
간단히 말해서, 우리는 sa를 어느 정도 수행한 다른 라이브러리를 사용했습니다.
6 IMPLICATIONS
시사점
시사점 1: 새로운 종속성을 선택하면서 보안을 고려하는 것은 개인 및 중소기업 개발자에게 비용이 많이 들 수 있습니다.
프로젝트에 포함할 라이브러리를 찾는 동안 개발자는 개발자 포럼에 있는 토론이나 소프트웨어 저장소에서 추출한 코드 메트릭과 같은 다양한 소스에서 정보를 찾고 결합해야 합니다. 이 프로세스에는 시간과 전문 지식이 필요하므로 숙련된 개발자 또는 소프트웨어 설계자(O3)가 수행하는 것이 좋습니다. 대기업에서 개발자는 때때로 사전 승인된 FOSS 및 자체 개발 라이브러리(O1)를 사용합니다. 이러한 회사의 개발자는 신뢰할 수 있음이 보장되므로 추가 조사 없이 이러한 라이브러리를 사용할 수 있습니다. 그러나 소규모 소프트웨어 개발 회사나 개인 개발자(예: 프리랜서)는 신뢰할 수 있는 소스가 없습니다. 숙련된 소프트웨어 아키텍트를 고용하는 것은 그들에게 상당한 비용이 들 수 있습니다.
연구 아이디어: SME 및 개별 개발자가 프로젝트에 대한 새로운 종속성을 선택하는 동안 보안을 고려할 수 있도록 복잡한 정보를 결합할 수 있습니다(예: 개발자가 액세스하고 이해할 수 있는 배지 또는 메타 메트릭 형태)(O13). 이러한 메타 메트릭은 다음 작업을 용이하게 할 것으로 예상됩니다.
- 라이브러리가 잘 지원되고 문제가 신속하게 해결됨을 입증합니다(O2 및 O9).
- 라이브러리가 알려진 보안 취약점(O13)의 영향을 받지 않음을 제안합니다.
- 라이브러리가 성숙하여 발견되지 않은 많은 버그와 보안 취약점을 가져오지 않는다는 것을 보여줍니다(O13).
- 라이브러리 자체 및 전이적 종속성에 대한 라이선스를 표시합니다.(O6).
시사점 2: LE 및 SME 개발자 모두 기능 개선과 함께 제공되지 않는 보안 수정 사항을 채택할 가능성이 더 높습니다.
보안 픽스(적어도 잘 지원되는 라이브러리의 경우)는 일반적으로 주요 변경 사항(O9)을 도입하지 않으며 기능 개선과 함께 번들로 제공되어서는 안 됩니다. 기능 개선으로 인한 변경 사항.
제한된 리소스(O10)의 제약 하에서 개발자는 이러한 업데이트를 무시하고 취약점을 유지하게 될 가능성이 큽니다. 대신 보안 수정 사항이 잘 표시되고 문서화되어 있으며 상당한 개발 노력이 필요하지 않은 경우 채택될 가능성이 더 높습니다.
연구 아이디어: 라이브러리 작성자가 항상 기능, 업데이트 및 보안 수정 사항을 별도로 유지할 수 있도록 연구원은 기능 및 보안 변경 사항을 구별할 수 있는 자동 접근 방식을 설계할 수 있습니다. 그런 다음 개발자는 두 개의 독립 라이브러리 버전을 출시하기로 결정할 수 있습니다. 라이브러리 사용자의 경우 연구원은 특정 라이브러리 버전에 기능 또는 보안과 관련된 변경 사항이 포함되어 있는지 여부를 식별할 수 있는 자동 분류기를 개발할 수 있습니다. 따라서 개발자는 보안 수정 사항을 즉시 채택하고(중단 변경 사항을 도입하지 않기 때문에) 기능 업데이트의 채택 일정을 예약할 수 있습니다.
시사점 3: LE 개발자는 자동화된 종속성 분석 도구를 채택하는 경향이 있는 반면 SME 및 개별 개발자는 사용을 권장하지 않습니다.
LE 개발자는 종속성의 보안을 고려하는 정책이 있으므로 종속성 분석 도구(O11)를 사용해야 합니다. 이에 반해 중소기업 및 개인 개발자는 프로젝트의 보안을 고려하는 절차가 부족합니다. 더욱이 그들은 새로운 기능 개발에 더 관심을 갖고 있기 때문에 종속성 분석 도구(O14)의 "성가신" 경고를 무시하고 이러한 문제가 심각하고 광범위할 경우에만 프로젝트 종속성의 보안 문제를 수정하는 것을 선호합니다. 모두 다 아는. 연구 아이디어: SME 및 개별 개발자의 종속성 분석 도구 채택을 촉진하기 위해 도구 작성자는 다음 개발자 요구 사항을 충족하도록 도구를 설계할 수 있습니다.
• 분석된 프로젝트에 실제로 영향을 미치는 취약한 종속성만 보고합니다(O14, O16 및 O18).
• 취약성(O18)에 의해 영향을 받는 분석된 프로젝트 부분의 식별;
• 종속성의 새 버전과 안전한 초기 버전을 모두 제안하여 개발자가 최상의 완화 전략을 선택할 수 있도록 합니다. 새 버전을 채택하거나 이전 버전으로 롤백(O16)합니다.
• 수정된 버전이 주요 변경 사항을 도입하는지 제안합니다(O16).
시사점 4: LE 개발자는 프로젝트 종속성 내에서 취약점을 수정하는 데 보다 능동적인 반면 SME 및 개인
개발자는 수동적으로 행동하는 경향이 있습니다.
LE 개발자는 때때로 취약점을 수정하고 풀 리퀘스트(O20)를 생성하여 의존하는 프로젝트에 기여합니다. 그러나 SME 및 개별 개발자는 종속 프로젝트를 지원하기에 충분한 시간, 기술 및 개발 리소스가 없을 수 있습니다. 따라서 그들은 종속성에 대한 커뮤니티 지원에 의존하는 경향이 있으며 취약성을 유지하거나(O18) 프로젝트의 일부 기능을 일시적으로 비활성화하는 것을 선호합니다11(O19). 연구 아이디어: 취약한 종속성에 사용할 수 있는 고정 버전이 없는 경우 개발자는 수동 분석을 수행하여 발견된 문제에 대한 대책을 고안합니다. 이 조치가 중요하기 때문에 함축 3에 제시된 요구 사항 외에 다음 측면(특히 LE 개발자의 경우)에 대한 종속성 분석 도구의 지원이 필요합니다.
개발자가 직접 확인하고 문제를 해결할 수 있도록 종속성 소스 코드에 액세스(O20)
• 유사한 기능을 가진 대체 라이브러리를 찾고 이 라이브러리로 전환하는 비용을 추정합니다(O21).
7 THREATS TO VALIDITY
유효성에 대한 위협
우리는 물질적 보상을 사용하지 않고 주제에 대한 관심만 기반으로 연구를 위해 개발자를 모집했습니다. 우리 연구에서 우리는 좋은 위치에 있는 산업 전문가로부터 정보를 받는 것을 목표로 했습니다. 따라서 우리는 경험을 공유하고 문제에 대한 의견을 말해줌으로써 개발 관행을 개선할 수 있는 가능성보다 더 좋은 보상을 생각할 수 없었습니다. 더욱이 개발자들은 프로젝트에 대한 종속성 분석 보고서를 생성하는 데 사용할 수 있는 도구의 프로토타입이 이미 있다는 사실에 동기를 부여받는 경우가 많습니다. 우리는 이 전략을 통해 해당 주제에 대한 적절한 수준의 지식을 가진 현장 전문가로부터 특히 귀중한 피드백을 받을 수 있었다고 믿습니다.
우리는 접근할 수 있는 개발자의 수를 늘리기 위해 눈덩이처럼 접근하는 방식을 적용했습니다. 이것은 잠재적으로 공통의 견해를 공유하는 동일한 개발 커뮤니티의 개발자를 끌어들일 수 있습니다. 이러한 편견을 완화하기 위해 다른 회사와 국가에서 온 개발자를 선택했습니다. 최종 인터뷰한 개발자들은 다양한 배경과 회사 위치를 가지고 있습니다. 따라서 우리는 이 위협이 미미하다고 믿습니다.
우리의 관찰은 인터뷰 대상자가 인식한 사실을 기반으로 합니다. 그것들이 반드시 현실을 반영하는 것은 아닐 수 있으므로 제시된 함의를 검증하기 위해서는 더 많은 질적 및 양적 연구가 필요합니다. 불행히도, 현장 관찰 연구는 얻기 어렵습니다. 예를 들어, de Souza와 Redmiles[10]는 총 23개의 인터뷰에 대한 2개의 사례 연구를 보고합니다. de Souza가 몇 주 동안 회사에 묻혀 있음에도 불구하고 '몇 명의 팀원들만이 며칠 동안 그림자를 드리는데 동의했습니다.' 유사하게 [42]는 274명의 개발자를 대상으로 설문조사를 수행했지만 개발자를 관찰하려면 그 중 44명을 모집하고 실험실에서 설계한 작업을 할당해야 했습니다.
현재 우리는 주로 개발자들에게 회사 내 종속성 관리 관행에 대해 질문했는데, 이는 FOSS 프로젝트 개발과 관련된 일부 문제를 숨길 수 있습니다. 그러나 요즘에는
개발자는 종종 FOSS 커뮤니티의 트렌드를 소비하거나 기여하거나 최소한 따라야 합니다. 일부 인터뷰 대상자는 산업 종사자지만 FOSS 프로젝트에 대한 자신의 기여에 대해 말했습니다. 따라서 우리는 이 연구에서 제시한 분석과 의미가 FOSS와 엔터프라이즈 컨텍스트 모두에서 작업하는 개발자에게 귀중한 통찰력을 제공한다고 믿습니다.
우리는 개발자 진술에 대한 우리의 해석을 제시합니다. 확증 편향을 최소화하기 위해 두 연구원은 인터뷰에서 관찰과 시사점을 개별적으로 추출했고, 세 번째 연구원은 분석 결과에 대한 추가 검증을 수행했습니다. 또한 한 페이지 분량의 결과 요약을 인터뷰 대상자와 공유하여 개발자와 결과 검증을 수행했습니다. 따라서 우리는 우리의 결과가 보고된 실제 종속성 관리 관행과 일치한다고 믿습니다.
8 CONCLUSIONS AND FUTURE WORKS
이 문서는 소프트웨어 종속성에 대한 개발자의 인식과 보안 및 기능 문제의 상대적 중요성에 대한 정성적 연구 결과를 보고합니다. 우리는 9개국에 위치한 대기업과 중소기업의 개발자들과 각각 30피트 정도 되는 25회의 반구조화된 인터뷰를 진행합니다.
모든 인터뷰는 응용 주제 분석의 원칙과 함께 전사되고 코드화되었습니다. 질적 연구 결과의 의미를 요약하면 다음과 같습니다.
• 개발자가 라이브러리가 잘 지원되고 성숙하며 보안 취약점의 영향을 받지 않는다는 것을 이해할 수 있도록 하는 상위 수준 메트릭을 사용하여 최적의 라이브러리(FOSS) 선택을 촉진할 수 있습니다.
• 종속성 업데이트는 종속된 프로젝트를 중단시키므로 중단되지 않은 경우 만지지 마십시오. 세상을 지배합니다. 채택하려면 보안 수정 사항을 잘 표시해야 하며, 주요 변경 사항을 도입하지 않으며 상당한 노력이 필요하지 않아야 합니다.
• 유용성을 극대화하기 위해 종속성 분석 도구는 종속 프로젝트에서 사용하는 라이브러리 조각과 관련된 경고를 생성하고 획기적인 변경을 도입할지 여부를 추정하는 것과 함께 가능한 완화 전략을 제안해야 합니다.
• 업데이트에 대한 강력한 저항을 감안할 때 일반 보안 경보는 무시된 '늑대를 위한 외침'으로 종료될 가능성이 높습니다. 실행 가능한 도구는 종속 프로젝트의 어느 부분이 종속성 취약점에 의해 실제로 영향을 받는지 결정하고 해당 라이브러리로 전환하는 비용의 추정과 함께 유사한 기능을 제공하는 대체 라이브러리를 제안해야 합니다.
더 많은 국가로 연구를 확장하는 것부터 다양한 유형의 산업(예: 금융 회사, 중요 인프라 또는 소셜 미디어)과 결과를 상호 연관시키는 것까지, 우리 연구에서는 여전히 몇 가지 뉘앙스를 다루지 않습니다. ). 우리와 커뮤니티 전체에서 가장 어려운 미래 작업은 개발자가 필요로 하는 종속성 및 보안 분석 도구를 개발하는 것입니다.
