[2020 devnexus] Developers Need to Take Notice – Malicious Attacks On Open Source Are Getting Worse

Speaker: Derek Weeks @weekstweets

Deck: https://speakerdeck.com/derekeweeks/devnexus-presentation-derek-weeks

For more, see table of contents


Fun

  • XKCD – reinvent the wheel – “We don’t want to reinvent the wheel, so every day we google image search “wheel” and whatever object comes up, that’s what we attach to our vehicles. Sure external dependencies carry risks, but so far, they’ve all been pretty good wheels”

Notes

  • If just moving fast, have a problem
  • DevOps teams use more open source
  • 70% deploy at least once a week
  • Challenge: be faster than evil
  • In past 5 years, breaches increased 70%
  • Can’t predict when vulnerability will come up. Have to use without knowing what will happen.

Attacks

  • Equifax is old news by now. Had opportunity to patch
  • Adversaries can also contribute to open source. ex: npm event-stream attack on CoPay
  • 2019 – Gems bootstrap-saas – added backdoor
  • Typo squatting
  • Backdoors
  • Happening to Docker, Python, Ruby, NPM, etc

Supply Chain

  • 2019 Software Supply Chain Report
    • suppliers (open source)
    • warehouses, (component repos)
    • manufacturers (softare dev teams)
    • finished goods (software applications)
  • Maven Central had over 200B downloads in 2019 alone. Almost 10% had known vulnerabilities they day they were downloaded.
  • JavaScript hit 10B package downloads in 2019 alone. Just over 51% had known vulnerabilities they day they were downloaded.
  • 85% of app is sourced from external suppliers

Enterprise vs Open Source

  • Multiple deploys per day vs versioned releases
  • Consistent Dev team vs fluid group of developers
  • Predictable/well resources vs variable resources
  • Deploymen tvs release frequency
  • Organizational performance vs popularity
  • Mean time to restore vs time to remediate vulnerabilities

Is it true?

  • TRUE: Projects that release frequently have better outcomes – more popular, attack more developers and higher level of support from foundations. Also, avoids problem of having to wait for all the transitive dependencies to be in a version we are using.
  • TRUE: Projects that update dependencies more frequently are general more secure
  • FALSE: Projects with fewer dependencies will stay more up to date. Interestingly, smaller teams tend to have less dependencies. Not clear if correlation or causationl
  • FALSE: More popular projects will be better about staying up to date

Behavioral clusters

  • Small teams; excellent time to update
  • Large teams; excellent time to update, often foundation supported, popular
  • Laggards – release slowly, more likely to be commercially supported
  • Features first – release frequently, but poor time to update
  • Caution – good time to update, but seldom completely up to date

Developers

  • 38% schedule dependency updates
  • 46% strive to use latest version
  • 50% have process to add new dependency
  • 30% have process to proactively remove problematic or unused dependency
  • 37% have automated tool to track, managed and/or ensure policy compliance of dependencies

If only do one thing

  • If stay on latest version, by default more secure and less security issues.

My take

Good talk. Especially once the projector issues were fixed. I lik the graphs and data behind the main points. I’ve seen similar presentations, but the newer parts/stats were still good to hear.

[2020 devnexus] afternoon keynotes

For more, see table of contents


Decoding the weather – Kait Parker

@weatherkait

  • IBM owns the weather company and app
  • IBM GRAF –  Global High-Resolution Atmospheric Forecasting System 
  • Weather is big business – lost productivity, spikes in sales, inciting new innovation, damage impact
  • Can lost half a billion dollars in a single snowstorm in Boston
  • Whereas a city like Atlanta shuts down for snow
  • Naual disasters increasing – both climate change and not building smart
  • Weather is data
  • Weather company has largest collection of weather data in the world
  • APIs for current data and forecasts
  • US had good technology for weather. Whole world does not.
  • GRAF – more precise, faster refresh, uses 400 GPUs on 90 IBM servers
  • Future: add sensors on planes
  • #CallForCode – international challenge for developers to mitigate impact of natural disasters
  • Project Owl won in 2018. For addressing communication when cell phone towers go down. Creates mesh network based on wifi to gather info of who needs help. Smallest nodes are duck links. They are linked to mama duck. A drone connects to papa duck which connects to first responders.
  • Team Promoteo won in 2019. Monitors first responders. Wear a device. Tracks current conditions and trends.
  • 2020 competition starts February 26

Dehuman Future – Ixchel Ruis

  • EM-DATE – international disaster database

(I had to leave before this one ended as I’m on the podcast the starts after the keynotes. Too bad. Ixchel is a great speaker)

[2020 devnexus] synchronized is obsolete

Speaker: Enrique Zamudio

For more, see table of contents


Classes

  • AtomicInteger
    • incrementAndGet()
    • compareAndSet()
  • AtomicReference
    • updateAndGet()
  • ConcurrentHashMap – methods on Map, but happens atomically
    • computeIfAbsent()
    • merge()
  • ConcurentSkipListMap
  • ConcurrentSkipListSet
  • LinkedBlockingQueue
    • Can take elements and deliver elements concurrently.
    • Every element delivered to exaclty one consumer
    • Unblocks consumers as long as something in queue
  • Locks – Lock, ReadWriteLock, ReentrantLock, CountDownLatch, CyclicBarrier, Semaphore, Phaser
    • ReentrantLock – execute code if can acquire lock
    • lock()
    • tryLock()
    • tryLock(10, SECONDS)
    • unlock()
  • Akka – project that implements Actor paradigm
  • vert.x – project for reactive – do things in single thread
  • Project Loom – lightweight threads. I thread takes 100MB just to exist; Project Loom is more like 2KB. Also no context switching.

Multiple processes

  • multiple copies of your jar
  • multiple vms with load balancer
  • synchronized or lock fails because each process can run code at same time
  • Can use database select … for update in database transaction so outside your process.
  • Similarly can use redis to set a lock with a random value. If the value matches, you know the lock is yours. If JVM crashes, lock stays. Can add lock timeout to avoid this
  • FencedLock – developed by Hazelcast Raft consensus model.

My take

I feel like I re-learn this topic every time I read the chapter in our book. (Scott wrote the chapter). I’m glad I went to this session. The more times I hear this, the more sticks. I had forgotten the project loom info so was definitely good to hear that again. The part about multiple processes was mostly new to me. (I just new about select for update)