Qualitaetsziele kontinuierlich im Auge behalten · 2020-05-25 · – Beinhaltet über 600 Kategorien für Software Schwächen – Buffer Overflows, Race Conditions, Cross Site Scripting,

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]:

Qualitätsziele kontinuierlich im Auge behalten

1.0

Qualitätsziele kontinuierlich im Auge behalten© Orientation in Objects GmbH

Gliederung

• In the beginning

• I just have really high standards

• For security and legal reasons

• Fail early, fail loudly

2

1

2

2


Gliederung





3


Been there, done that (1)

4

BuildTool

CI Server

DeveloperTeam

VCS

CI ServerResult Page

Update

Commit

Build

Results

Publish

Inform

3

4

3


Been there, done that (2)

5

Test ToolsBuild &

Test ToolsCI Server

DeveloperTeam

VCS

CI ServerResult Page

Update

Commit

BuildBuild & Test

Results

Publish

Inform


Put it to the test

• „Test“ impliziert in der Regel Code Ausführung (Dynamic Analysis)– Dazu gehören Unit, Integration, System und Acceptance Tests

• Quellcode kann auch statisch analysiert werden

– Entweder durch Menschen im Code Review oder durch Tools

• Eines der ersten Tools ist „lint“ für C von 1978

6

/* might be wrong */

while (x = 1) {

…

}

5

6

4


While we’re at it…

• Zeitgleich mit CI Servern entstehen neue statische Analyse Tools

– Checkstyle, FindBugs, PMD, Copy/Paste Detector, …

• Oft Kommandozeilen basiert mit IDE Plugins von dritter Seite– Verdopplung von Konfiguration, Einsatz unterschiedlicher Versionen

• Rechenleistung häufig ein Problem– „Schwache“ Entwicklerrechner, CI Anti-Pattern „Slow Hardware“

• Tools haben jeweils eigenen Fokus, überschneiden sich aber auch– Erste Plattformlösungen entstehen, darunter SonarQube

7


Demonstration – SonarQube

8

7

8

5


Gliederung





9


Level up

• Bisherige Analysen sind primär auf Code Ebene

• Object Management Group (OMG) unterscheidet drei Analyse Level– Unit Level – single unit of code

– Technology Level – integrated collection of code units

– System Level – all the different code units and layers of technology

• Für Technology / System Level sind spezialisierte Tools von Vorteil

10

9

10

6


Another brick in the wall

• Besonders für Software Architektur ist Qualitätskontrolle wichtig– Initiale Architekturen sind in der Regel gut, …

– … verfallen aber, wenn Projekte wachsen und Entwickler wechseln

• Für Java etwa existieren viele Konvention und (de facto) Standards– Die aber nicht immer jeder kennt oder gerade vor Augen hat

• ArchUnit erlaubt die Einhaltung von Architekturregeln zu prüfen– API zur Erstellung einfacher Java Unit Tests für Java Architekturen

11


Demonstration – ArchUnit

12

(Quelle: https://www.archunit.org/userguide/html/000_Index.html#_what_to_check)

11

12

7


And then what?

• Zusammen mit Tools bildet sich Klassifizierung und Kategorisierung

• Ziel ist einheitliche Kommunikation– Welche Fehler gibt es und wie kritisch sind diese?

– Was wurde bei uns in der Entwicklung geprüft?

– Welches Tool kann welche Fehler entdecken?

– Was kann ich machen wenn ein bestimmter Fehler entdeckt wird?

• Entstehung „Common Weakness Enumeration (CWE)“ System– Beinhaltet über 600 Kategorien für Software Schwächen

– Buffer Overflows, Race Conditions, Cross Site Scripting, …

– Tools können als „CWE-compatible“ registriert werden

13


The best of the best of the best

14

(Quelle: http://cwe.mitre.org/top25/index.html)

13

14

8


The Times They Are A-Changin'

• Ab 2010 Continuous Delivery und Deployment Pipelines– Jede Pipeline Stage ist ein zu passierendes „Quality Gate“

• Ergebnisse aus Analyse Tools können Teile von „Quality Gates“ sein– Klassifizierungssysteme wie CWE als Basis zur Einschätzung– „Leave this world a little better than you found it”

• CD und SCM Server sind gängige „Andockstellen“

15

(Nach „Continuous Delivery“/J. Humble, D. Farley)

AutomatisierteAutomatisierteAkzeptanz

Tests

Nutzer-abnahme

Releasein Produktion

Artefaktebauen undUnit Tests

Versions-kontrolle

DeliveryTeam

Check inTrigger

Trigger

Manualapproval Manual

approvalFeedback

Feedback

Feedback


Demonstration – SonarQube Quality Gates

16

15

16

9


Gliederung





17


• „[CD] helps reduce the cost, time and risk of delivering changes... “

• Security kann kein nachgelagertes / orthogonales Thema sein

• Neue Schlagworte wie DevSecOps oder Rugged Manifesto– „[…] I refuse to be a source of vulnerability or weakness.“

• Unser Code wird ja zum Glück getestet und analysiert …

I feel the need – the need for speed

18

Time

Cha

nge

Time

Cha

nge

(Quelle: http://en.wikipedia.org/wiki/Continuous_delivery)

17

18

10


It Wasn't Me

• Anwendungen sind nicht komplett selbst entwickelt (OSSRA Report)– 95% aller Anwendungen verwenden Open Source

– Durchschnittlich 105 Open Source Komponenten je Anwendung

– 67% aller Anwendungen enthielten „Open Source Vulnerabilities“

– 40% dieser Vulnerabilities je Anwendung wurden als „severe“ eingestuft

• Das Problem ist nicht neu– Durchschnittsalter der obigen Vulnerabilities war 1894 Tage (5+ Jahre)

– Häufig gab es neue korrigierte Versionen der jeweiligen Komponenten

• Warum wird nicht gehandelt?– Komponenten Updates sind aufwendig (Code Änderungen, Testing)

– Application Dependencies oft nicht Teil von Ops Patching Aktivitäten

– Dev Teams sind sich der Probleme häufig nicht bewusst

19


Big Data

• Sammlung aller „Common Vulnerability and Exposures (CVE)“– MITRE Corporation stellt Liste bereit

– Liste wird in „U.S. National Vulnerability Database (NVD)“ synchronisiert

– NVD ergänzt weitere Informationen

• CVE Eintrag in der NVD enthält– Beschreibung der Vulnerability oder Exposure

– Einstufung gemäß „Common Vulnerability Scoring System (CVSS)“

– „Common Platform Enumeration (CPE)“ Liste betroffener Plattformen

20

19

20

11


Separation of Concerns

• Klarer Unterschied zwischen CWE und CVE– Common Weakness Enum versus Common Vulnerability & Exposures

– Weakness ist Problem Typ, der zu konkreter Vulnerability führen kann

– CVE-2017-7160 in iOS pre-11.2 ist eine Ausprägung von CWE-119

• Benennung betroffener Ressourcen per CPE oder GAV– Common Platform Enumeration – Namensstandard für IT Komponenten

– Group-Artifact-Version – Unique Artifact Coordinates in Apache Maven

– Keine Mapping Datenbanken öffentlich verfügbar

– cpe:/a:pivotal:spring_framework:3.2.0

– org.springframework:spring-core:3.2.0.RELEASE

21


All Together Now

• Verwendete Open Source Komponenten müssen geprüft werden– Komponenten sind bekannt, explizit oder per Dependency Management

– CVE Liste liegt vor und wird fortlaufend aktualisiert

• Tool zur Überprüfung „Dependency-Check“– Open Source „Software Composition Analysis (SCA)“ Tool

– Flagship Project des „Open Web Application Security Project (OWASP)”

• Dependency-Check ermittelt Dependencies durch diverse Analyzer– Anhand der Dependencies werden die CPEs eines Projekts gesammelt

– Für die gesammelten CPEs wird ein Bericht mit allen CVEs erstellt

– Verwendet werden die aktuellen online CVE Daten der NVD

22

21

22

12


Demonstration – OWASP Dependency Check

23


I Fought The Law

• Komponenten sind nun sicher, aber ist der Einsatz überhaupt legal?

• Unter Umständen sind nicht alle Lizenzbedingungen akzeptabel– Zum Beispiel „Copyleft“ Lizenzen

• „Lizenzkontrolle“ beschränkt sich häufig auf reine Auflistung– „mvn project-info-reports:dependencies“, License Maven Plugin

• Security und Lizenzen besser zentral kontrollieren (Governance)– Komponenten Freigabe unter Aspekten Lizenz, Security, Architektur, …

24

23

24

13


Storing JARs in CVS is so yesterday

• Deklarative Dependency Verwaltung seit Maven de facto Standard– Es entstehen Online Repositories für Open Source Komponenten

• Neue Notwendigkeiten für Tooling Infrastruktur– Proxy für öffentliche Repos (Verfügbarkeit, Performance, Bandbreite)

– Betrieb eigener Repositories (für nicht öffentliche und eigene Artefakte)

• Binary Repository Manager Einsatz ist Best Practice– „ application designed to manage repositories of binary components“

• Alternative Bezeichnung Artefakt Repository Manager– Diverse Open Source und kommerzielle Produkte verfügbar

25


But wait, there's more!

26

VCS

Commit StageProduktiv

Stage

Performance Test Stage

NutzerabnahmeNutzerabnahmeStage

Artefakt Repository

Infrastruktur- und AnwendungskonfigurationQuellcode

Akzeptanz TestStage

(Nach „Continuous Delivery“/J. Humble, D. Farley)

• Delivery Pipelines unterstreichen Notwendigkeit von Artefakt Repos– „assemble […] binaries and store them in an artifact repository“

25

26

14


You Got Lucky

• Viele Repo Manager bieten Komponenten Policies und Quarantäne– Produkte sind häufig kommerziell (je nach gewünschtem Feature Set)

– Zum Beispiel Sonatype Nexus Firewall / Lifecycle oder JFrog Xray

27

(Quellen: https://www.sonatype.com und https://www.jfrog.com)


Gliederung





28

27

28

15


Let me Google that for you (1)

• ACM Paper „Lessons from building static analysis tools at Google”

• „Our experience attempting to integrate static analysis into Google’s

workflow […]”

• Versuch hat diverse Erkenntnisse geliefert– Finding bugs is easy – Einfaches Tooling ist ausreichend

– Developers will not go out of their way – Dashboards bringen nichts

– Developer happiness is key – Nutzen muss klar erkennbar sein

– Do not just find bugs, fix them – Fehler fixen nicht finden ist das Ziel

– Crowdsource analysis development – Devs dürfen beitragen

• Welches Fazit kann daraus gezogen werden?

29


Let me Google that for you (2)

• „We advocate […] pushing workflow integration as early as possible“

• „When possible, checks are enabled as compiler errors“– „[…] while [developers] are still amenable to making changes“

• „Code Review is a sweet spot for displaying analysis warnings“– „[…] present(s) issues only when […] changing the code in question“

30

29

30

16


Tool Time

• Code Insight in Atlassian Bitbucket Server

– „presenting important development information directly on pull requests“

• Open Source Tool namens „Error Prone“ von Google

– Integriert sich in Java Compiler und findet Fehler zur Compile Zeit

– Bietet Plugin Mechanismus für eigene Checks

– Unterstützt automatisches Patching und Refactoring

31

(Quelle: https://community.developer.atlassian.com)


Demonstration – Error Prone

32

31

32

17


Zusammenfassung

• Zahlreiche Toolsuiten für Code und System Analyse verfügbar

• Klassifizierungssysteme für Priorisierung und Quality Gates nutzbar

• Auch verwendete Komponenten und nicht nur eigenen Code prüfen

• Security und Lizenz Richtlinien für externe Komponenten definieren

• Für Richtlinien Einhaltung bei Komponenten Bereitstellung sorgen

• Erfolgskontrolle nicht anhand gefundener sondern beseitigter Fehler

• Entwickler überzeugen und guten Analyse Output früh bereit stellen

33


If you remember one thing

34

„A fool with a tool is still a fool.”

(Grady Booch)

33

34

18


Links (1)

• SonarQube: Continuous Inspection– https://www.sonarqube.org/

• How to Deliver Resilient, Secure, Efficient, and Easily Changed IT Systems in Line with CISQ Recommendations– https://www.omg.org/news/whitepapers/CISQ_compliant_IT_Systemsv.4-

3.pdf

• ArchUnit: Unit test your Java architecture– https://www.archunit.org/

• Common Weakness Enumeration: CWE– https://cwe.mitre.org/

• Rugged Software– https://ruggedsoftware.org/

35


Links (2)

• The State of Open Source Security in Commercial Applications– https://www.blackducksoftware.com/sites/default/files/images/Download

s/Reports/USA/OSSA16_Rpt_UL.pdf

• CVE - Common Vulnerabilities and Exposures (CVE)– https://cve.mitre.org/

• National Vulnerability Database (NVD)– https://nvd.nist.gov/

• Common Vulnerability Scoring System (CVSS)– https://www.first.org/cvss/

• Common Platform Enumeration (CPE) Dictionary– https://nvd.nist.gov/products/cpe/

36

35

36

19


Links (3)

• Guide to naming conventions on groupId, artifactId, and version– https://maven.apache.org/guides/mini/guide-naming-conventions.html

• Open Web Application Security Project (OWASP)– https://www.owasp.org/

• OWASP Dependency Check– https://www.owasp.org/index.php/OWASP_Dependency_Check/

• Apache Maven Project Info Reports Plugin– https://maven.apache.org/plugins/maven-project-info-reports-plugin/

• License Maven Plugin– https://www.mojohaus.org/license-maven-plugin/

37


Links (4)

• Best Practice - Using a Repository Manager– https://maven.apache.org/repository-management.html

• Nexus Platform Overview– https://www.sonatype.com/products-overview/

• JFrog - Universal Artifact Management for DevOps Acceleration– https://jfrog.com/

• Lessons from Building Static Analysis Tools at Google– https://cacm.acm.org/magazines/2018/4/226371-lessons-from-building-

static-analysis-tools-at-google/fulltext/

38

37

38

20


Links (5)

• Introducing Code Insights for Bitbucket Server, continuously improve code quality with quick actionable feedback from apps– https://community.developer.atlassian.com/t/introducing-code-insights-

for-bitbucket-server-continuously-improve-code-quality-with-quick-

actionable-feedback-from-apps/23148

• Error Prone– http://errorprone.info/

39



[email protected]

??

? ?

????

Fragen ?

40

39

40

21



[email protected]

Vielen Dank für Ihre Aufmerksamkeit !

41

Documents

Qualitaetsziele kontinuierlich im Auge behalten · 2020-05-25 · – Beinhaltet über 600 Kategorien für Software Schwächen – Buffer Overflows, Race Conditions, Cross Site Scripting,