Tag Archives: oss

[kcdc 2022] devops, 12-factor and open source

Posted on by
Reply

Speaker: Justin Reock @jreock

For more, see the table of contents

References

  • “It’s no longer the big beating the small, but the fast beating the slow”
  • Book: The Goal – Eliyahu Goldratt. Theory of Constraints for Business Productivity. Business fiction.
  • Book: Phoenix Project. Similar to The Goal but software business fiction
  • Book: The Machine that Changed the World
  • Book: Organizational physics – the science of growing a business. Short. Why businesses fail

Constraints

  • Change focus from costs to throughput
  • Layoffs reduce costs but decreasing costs
  • Need to both decrease costs and increase throughput
  • Cost = organizational cost
  • Inventory = Code
  • Throughout = Money
  • Doesn’t really matter what improve as long as constantly improving something because entropy makes things worse if do nothing.

DevOps

  • Chose supported free software and open first policy
  • Deploy in cloud/containers
  • If do container and not 12 factor, don’t see benefits
  • APIs are everything now. Govern APIs
  • Build fail-fast culture. Near instant release (and therefore patch)

Problems with Closed Development

  • Slow to obtain
  • Inflexibility in growth/scaling. ex: fixed number licenses
  • Can’t modify
  • Can’t benefit from others
  • Lose growth vs giving competitors features
  • Less oversight, less security

Path

  • Individual physical servers
  • Virtual machines
  • Containers (stripped down OS powered by one underlying OS)
  • Created ecosystem with proliferation of microservices – Kubernetes (Greek word for captain). Now can have virtual datacenter in a box

12-Factor

Series of characteristics to increase odds of success in cloud/containers. The less you do for an app, the more friction you will have going to cloud/containers.

https://12factor.net

  • Codebase – in version control, deploy often
  • Dependencies – explicitly declare and isolate
  • Config – store in env. Env variables popular again
  • Backing Services – treat as attached resources
  • Build. release, run – separate strategies
  • Processes – one or more stateless processes
  • Port binding – how to expose services
  • Concurrency – Docker gives for free
  • Disposability – fast startup, graceful shutdown
  • Dev/prod parity – keep as similar as possible
  • Logs – push events out to central system via event streams
  • Admin processes – manage as one offs

Coding

  • About flow
  • Use left and right brained activities
  • Problem solving – hypothesis and feedback from build system.
  • Feedback feels good and keeps in state of creative flow
  • The longer you wait for a build, the less happy you are
  • Few track local build times.
  • Waste waiting for and debugging local and CI builds
  • 10x developer – organizational culture matters more than individuals

Benefits of faster cycle time

  • Less idle time
  • Less content switching – people can’t multi task. Also, bad for brain to try
  • More focus
  • Build more often
  • Earlier quality checks
  • Few expensive downstream incidents
  • Smaller change sets
  • Fewer merge conflicts
  • More efficient troubleshooting
  • Faster mean time to recovery

Trends

  • 1970s – JIT manufacturing
  • 1980s – Business process reengineering
  • 1990s – Change management
  • 2000s – Agile, Lean Six Sigma
  • 2010s – DevOps
  • 2020+ DPE (developer productivity engineering)

DPE

  • Engineering approach to productivity
  • Acceleration and analytics tech to improve dev experience
  • build cache – Gradle has option to use. Also Gradle Enterprise brought to Maven
  • Aligns with management goals – faster TTM (time to market), reduced cost, improved quality
  • https://gradle.com/learning-center-by-objective/
  • https://gradle.com/developer-productivity-engineering/handbook/

My take

Good mix of current and historical examples from outside computing (I didn’t blog about the history part), I hadn’t heard of 12-Factor prior to reading the abstract for this talk. I would have liked more time on it since it is a third of the title, but the talk flowed well as is.

[devnexus 2022] hacking the OSS supply changes

Posted on by
Reply

Speaker: Stephen Chin

@steveonjava

Link to table of contents

———————

Theme is security with sci fi references

Examples

  • Equifax data breah – from not patching Struts for at least two months
  • Solarwinds – hacked TeamCity instance injected
  • log4shell – zero day in log4j core. Affected almost all systems. Could send class file and having it excecute on the serer
  • spring4shell

Binary repos

  • Which do you trust?
  • npm, pypi, rubygems, maven central
  • Like picking up thumb drive off sidewalk and plugging into your production server

Dependency confusion attack

  • Sci fi – Matrix – agents disguised theselves as other people
  • package mining
  • npm has no security on namespaces
  • Can use same name as a company internal package and give it higher version number
  • If grabing latest version, pull mallicious package
  • When pull from npm, announcing what package you have
  • Artifactory resolves against internal repo first. Protects even if using virtual repo which mixes public and private content

Supply Chain Attacks

  • Sci fi: millinium falcon
  • Assume depedencies built on a clean system
  • Anyone can upoad to pipi
  • About 400 zero day volunerabiities in open source/cloed source/OS, embedded systems, etc
  • Sveder uploaded library to go to his website
  • JFrog scans looking for suspicious Python code behavior
  • noblesse – “optimizes your PC for python” – steals credit card/passwords and sends via dicord
  • pythatoras – supposed to help with calculations but does remote code executio

Namespaces

  • Sci fi: War games
  • Moscow – Russia and Idaho
  • St Petersburg – Russian and Florida
  • azure-core-tracing is proper name. Created core-tracing.
  • NPM took down once repored. At least 218 packages affected.
  • Stole personal data
  • Think bug bounty of test because minimal and not steaing credit cards

Pyrisa

  • Scitfi: Avengers
  • Need automated (IronMan), trustworthy (Black Widow) and dependable (Captain America)
  • trusted binary network – secure by defaut, reliable inimal outages), open
  • peer to peer
  • multi-node verification
  • reproducabe build trust model

Websites

  • research.jfrog.com

My take

I hadn’t heard of all those attacks so learned about the Python ones. The sci fi element was a nice touch. As was the community picture with a ton of people on stage.

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

Posted on by
Reply

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.