The document discusses continuous delivery and releasing software frequently through automation. It emphasizes building quality into the software process from the start using techniques like automated testing, configuration management, and continuous integration. This allows teams to reliably release new versions of software whenever required through the use of a deployment pipeline that automates testing, deployment and monitoring. Frequent releases help reduce risks and gather feedback to build the right product.
Clash of the Titans: Releasing the Kraken | NodeJS @paypalBill Scott
FluentConf 2013 Plenary.
http://www.youtube.com/watch?v=tZWGb0HU2QM&list=SP055Epbe6d5avZGXwE5u039VQq_oQFgrc&index=9
How do you take a large titan like PayPal and move it from a culture of a long shelf life to a culture of rapid experimentation? You set the UI free by adding liberal doses of NodeJS, JavaScript templating & libraries, JSON, Github and Lean Startup/UX. Bill will explain the transformation that is in process to revolutionize the technical and experience stack at PayPal.
Continuous delivery a happier, safer alternative to release trainsThoughtworks
This document discusses principles and practices for continuous delivery including automating the build, deployment, testing and release process. It emphasizes reducing risk through techniques like feature toggles, blue-green deployments, canary releasing and implementing a production immune system. It also stresses the importance of collaboration between developers, testers and operations personnel.
Lean Engineering: How to make Engineering a full Lean UX partnerBill Scott
In 1999, PayPal's name was synonymous with innovation. In fact, the so called PayPal Mafia (original founders) went on to establish Tesla, SpaceX, YouTube, Skype and other startups. They also provided the early investments of many of the most innovative companies on the internet today. But over time that innovation slowed to a crawl.
In 2011 a number of things begin to come together for PayPal that started its journey back to innovation. This is the story of that reboot and how engineering has played a key role in partnering directly with product and design to move from a culture of products having a long shelf life, to one of rapid experimentation.
In this talk, Bill will outline the principles of Lean Engineering; principles for engineering that enable learning. Drawing from his experience leading User Interface Engineering at both Netflix & PayPal, Bill will walk you through the key principles your engineering team will need to adopt to be that enabler for product and design in your organization. This talk will not just inspire you, but it will also give you some hard earned advice on making this a reality in your organization.
bringing design to life with lean ux & lean engineering - Lean Day West 2013Bill Scott
What does a good Lean UX working rhythm look like for designers & engineers? In this workshop, Bill & one of his design partners at PayPal, Cody Evol, will guide you through this experience. A set of principles, patterns (and anti-patterns), best practices, technologies & tools will be explored in this hands-on workshop leaving you with a clear understanding of how to mesh prototype & production.
Enabling Lean with Tech: lessons learned applying lean at paypalBill Scott
Couple of lessons learned with changing the technology stack at PayPal to support Lean UX methodologies.
This talk is happening as part of the Lean Startup in the Enterprise talk with Jeff Gothelf on Tues, Dec. 4, 2012.
The document is a presentation on writing high quality code. It discusses what makes software good and introduces six qualities of good code: cohesive, non-redundant, encapsulated, assertive, testable, and explicit. Each quality is then explained in more detail, highlighting examples of good practices and pathologies to avoid. The presentation concludes by stating that following these six code qualities can guide developers to write better code.
The document discusses how agile teams can work at scale to deliver large, complex systems. It proposes that teams coordinate through integrating teams that ensure communication and integration across context boundaries. Technical practices like continuous integration and shared test suites help maintain the system. Social structures like component shepherds and tech councils provide guidance and oversight of the overall system. The goal is lateral coordination between self-organizing teams rather than top-down hierarchies.
Clash of the Titans: Releasing the Kraken | NodeJS @paypalBill Scott
FluentConf 2013 Plenary.
http://www.youtube.com/watch?v=tZWGb0HU2QM&list=SP055Epbe6d5avZGXwE5u039VQq_oQFgrc&index=9
How do you take a large titan like PayPal and move it from a culture of a long shelf life to a culture of rapid experimentation? You set the UI free by adding liberal doses of NodeJS, JavaScript templating & libraries, JSON, Github and Lean Startup/UX. Bill will explain the transformation that is in process to revolutionize the technical and experience stack at PayPal.
Continuous delivery a happier, safer alternative to release trainsThoughtworks
This document discusses principles and practices for continuous delivery including automating the build, deployment, testing and release process. It emphasizes reducing risk through techniques like feature toggles, blue-green deployments, canary releasing and implementing a production immune system. It also stresses the importance of collaboration between developers, testers and operations personnel.
Lean Engineering: How to make Engineering a full Lean UX partnerBill Scott
In 1999, PayPal's name was synonymous with innovation. In fact, the so called PayPal Mafia (original founders) went on to establish Tesla, SpaceX, YouTube, Skype and other startups. They also provided the early investments of many of the most innovative companies on the internet today. But over time that innovation slowed to a crawl.
In 2011 a number of things begin to come together for PayPal that started its journey back to innovation. This is the story of that reboot and how engineering has played a key role in partnering directly with product and design to move from a culture of products having a long shelf life, to one of rapid experimentation.
In this talk, Bill will outline the principles of Lean Engineering; principles for engineering that enable learning. Drawing from his experience leading User Interface Engineering at both Netflix & PayPal, Bill will walk you through the key principles your engineering team will need to adopt to be that enabler for product and design in your organization. This talk will not just inspire you, but it will also give you some hard earned advice on making this a reality in your organization.
bringing design to life with lean ux & lean engineering - Lean Day West 2013Bill Scott
What does a good Lean UX working rhythm look like for designers & engineers? In this workshop, Bill & one of his design partners at PayPal, Cody Evol, will guide you through this experience. A set of principles, patterns (and anti-patterns), best practices, technologies & tools will be explored in this hands-on workshop leaving you with a clear understanding of how to mesh prototype & production.
Enabling Lean with Tech: lessons learned applying lean at paypalBill Scott
Couple of lessons learned with changing the technology stack at PayPal to support Lean UX methodologies.
This talk is happening as part of the Lean Startup in the Enterprise talk with Jeff Gothelf on Tues, Dec. 4, 2012.
The document is a presentation on writing high quality code. It discusses what makes software good and introduces six qualities of good code: cohesive, non-redundant, encapsulated, assertive, testable, and explicit. Each quality is then explained in more detail, highlighting examples of good practices and pathologies to avoid. The presentation concludes by stating that following these six code qualities can guide developers to write better code.
The document discusses how agile teams can work at scale to deliver large, complex systems. It proposes that teams coordinate through integrating teams that ensure communication and integration across context boundaries. Technical practices like continuous integration and shared test suites help maintain the system. Social structures like component shepherds and tech councils provide guidance and oversight of the overall system. The goal is lateral coordination between self-organizing teams rather than top-down hierarchies.
The document describes the evolution of Facebook's big data architectures from 2007 to 2011. It started with a traditional data warehouse using MySQL and grew significantly over time. Facebook moved to Hadoop and Hive in 2008 to enable data science at scale and store all data online. In 2009, they further democratized data with tools to make it accessible. Later improvements focused on isolation, efficiency, utilization and monitoring to control the growing chaos. By 2011, they developed Puma for real-time analytics and Peregrine for fast queries to go beyond Hadoop.
This document discusses rethinking test-driven development (TDD) in a pragmatic way. It questions some common beliefs around TDD, such as whether tests always need to be written first or if they guarantee good design. While tests can help focus development and allow safer changes, they may also constrain refactoring and evolution. A pragmatic approach to TDD uses tests to enhance practices but considers more techniques than just unit tests to validate requirements are met. It emphasizes combining techniques and avoiding dogmatic views of TDD.
This document discusses using story maps as test plans and for cross-cutting discovery. It suggests that story maps can help teams learn through mapping user journeys, foster co-ownership, and connect teams by example. Story maps may also drive testing by showing examples and specifications. The document advocates using story maps for product-driven testing at different levels and across perspectives to discover cross-cutting challenges.
This document summarizes a presentation about the mobile security Linux distribution Santoku Linux. It discusses how Santoku Linux was created by modifying Lubuntu to include mobile forensic and security tools from the company viaForensics. Some key tools discussed include AFLogical OSE for Android logical acquisitions, iPhone Backup Analyzer, and utilities for analyzing mobile malware samples. Real-world examples of analyzing the Any.DO task manager app and Korean banking malware are also provided.
Web security-–-everything-we-know-is-wrong-eoin-kearydrewz lin
1) Web application security is often approached incorrectly, focusing too much on annual penetration tests and compliance, rather than ongoing monitoring and prevention through the development process.
2) Many vulnerabilities are introduced through third party libraries and dependencies, which are not properly tested or managed. Continuous testing across the full software supply chain is needed.
3) Not all vulnerabilities are equal - context is important. A risk-based approach should prioritize the most critical issues based on factors like impact, likelihood, and the development environment. Compliance alone does not ensure real security.
The document discusses concepts related to continuous delivery and deployment pipelines. It advocates building quality into software through automated testing and collaboration between developers, testers and operations teams. Continuous delivery aims to make software production-ready at any time by implementing configuration management, continuous integration, and automated testing in a deployment pipeline that provides feedback at every change. This reduces risk and enables frequent, reliable releases that are tied to business needs rather than operational constraints.
The document discusses maintaining high-quality acceptance tests. It provides 5 principles: 1) Treat tests like production code, 2) Interact with the system under test like a user, 3) Continuously curate user journeys, 4) Have collective ownership of acceptance tests, 5) Tests own their own data. The presentation emphasizes that quality is a shared responsibility and tests require ongoing care like production code. Exhaustive story-level testing alone does not lead to maintainable test suites.
There's a recording of this talk at Agile 2012 here: http://www.youtube.com/watch?v=v-L_2y6g5DI
Creating automated end-to-end functional acceptance tests is hard. Maintaining them over time is harder. Some agilistas even claim that the cost outweighs the benefit. In this lecture we present five principles for creating valuable, maintainable acceptance test suites. We discuss practices such as layering acceptance tests to reduce coupling between the test harness, and talk about how teams should be organized in order to efficiently manage acceptance test driven development. The core of the talk discusses how to manage the evolution of acceptance tests by organizing them as scenarios rather than as suites of story tests. Finally we show how to manage data for acceptance tests.
This document discusses the concept of mobile first service design. It notes that last year, smartphones became the new personal computer as their usage surpassed desktop computers. It defines mobile first as designing services with mobile devices as the primary focus from the start. It provides examples of businesses and technologies that have seen success through mobile-first approaches. It discusses challenges like identity, privacy and input methods when designing for mobile and the importance of a minimum viable product approach through experimentation.
JDD 2016 - Joseph W. Yoder - Deliver Fast "With Confidence"PROIDEA
When developing and delivering large, complex systems it can be all too easy to only focus on features and overlook software qualities specific those related to software architecture. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with issues related to evolving the architectures, specifically when trying keeping the system working while making significant improvements when adding functionality. However, time has shown that various Agile practices are not sufficient to prevent or eliminate Technical Debt which can ultimately affect reliability. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture. If there is not enough attention on the architecture and code base, ultimately technical debt will creep in to the point where it can become hard to delivery quickly and with confidence.
Two important principle that can help teams deliver more quickly and with confidence is to focus on code quality and delivery size. Small frequently delivery with constant attention to a good code base is crucial to being able to sustain faster delivery with confidence. Often teams evolve to continuous delivery with some limited success, however issues arise when there is not good validation through tests and constant attention to the code quality. Practices that can help keep the code clean or from getting muddier include: Testing, Divide & Conquer, Gentrification, Quarantine, Refactoring, and Craftsmanship. This talk will examine techniques such as Continuous Integration, Continuous Inspection, Continuous Delivery as well as other techniques to pay good attention to code quality allowing teams to delivery more quickly and with confidence.
7 Deadly Sins of Agile Software Test AutomationAdrian Smith
The document outlines 7 deadly sins of automated testing: envy, gluttony, lust, pride, sloth, rage, and greed. It discusses flaws in comparing manual and automated testing, overreliance on commercial tools, focus on user interfaces over architecture, lack of collaboration, poor maintenance, frustration with brittle tests, and attempts to cut costs rather than improve quality. The document advocates for collaboration, technical best practices, and treating tests as critical code.
SpeakerConf: my findings in trying to use this functional programming busines...Phil Calçado
The document summarizes the findings of someone experimenting with functional programming. It discusses whether tests are good for designing pure functions, dealing with impedance between functional and object-oriented code, and how static typing could potentially replace some testing by catching errors. It also mentions potential relationships between category theory and software engineering.
The document discusses building vibrant internal and external communities through an enterprise social media and collaboration framework. It proposes integrating social features and communities into core business processes, and establishing metrics to measure the impact on business objectives like return on investment and knowledge reuse. A case study from Sun Microsystems shows how their collaboration platform improved win rates and margins through increased document reuse.
This document discusses how Etsy enables rapid experimentation through continuous deployment and metrics-driven development. Key points include deploying small code changes frequently using feature flags and ramp-ups, measuring everything with tools like StatsD, optimizing for learning by running many experiments, and gaining confidence to change through quantitative metrics. The goal is to make failures cheap and iterate quickly to find product-market fit.
How to be a Lean Product Developer? @Agile Riga Day 2012Marko Taipale
The document provides guidance for lean product development. It recommends:
1. Validating business ideas through customer development and getting feedback to turn ideas into a series of testable hypotheses rather than guesses.
2. Building software faster using techniques like acceptance test-driven development (ATDD) and just-in-time architecture to minimize waste and inventory in the development process.
3. Measuring key metrics to understand customer needs and prioritize features, determine when requirements are met, and track progress over time.
The document discusses unit testing and functional programming concepts. It provides examples of testing AMQP (Advanced Message Queuing Protocol) code in a functional style by separating pure and impure code. Functions are defined to construct arguments for the queue_declare method in a testable way. This allows testing each part in isolation and combining them to test full functionality.
Building better products requires up-front investment in product planning and strategy. This talk will cover basic User Experience tools and techniques for breaking down a project, planning the architecture, organizing development, and communicating those ideas to colleagues and technical partners. We will cover creative ways to generate ideas and collaborate with your stakeholders. We’ll also introduce you to conceptual tools that will help solve problems visually as well as design activities including sketching and wireframing.
The document describes the evolution of Facebook's big data architectures from 2007 to 2011. It started with a traditional data warehouse using MySQL and grew significantly over time. Facebook moved to Hadoop and Hive in 2008 to enable data science at scale and store all data online. In 2009, they further democratized data with tools to make it accessible. Later improvements focused on isolation, efficiency, utilization and monitoring to control the growing chaos. By 2011, they developed Puma for real-time analytics and Peregrine for fast queries to go beyond Hadoop.
This document discusses rethinking test-driven development (TDD) in a pragmatic way. It questions some common beliefs around TDD, such as whether tests always need to be written first or if they guarantee good design. While tests can help focus development and allow safer changes, they may also constrain refactoring and evolution. A pragmatic approach to TDD uses tests to enhance practices but considers more techniques than just unit tests to validate requirements are met. It emphasizes combining techniques and avoiding dogmatic views of TDD.
This document discusses using story maps as test plans and for cross-cutting discovery. It suggests that story maps can help teams learn through mapping user journeys, foster co-ownership, and connect teams by example. Story maps may also drive testing by showing examples and specifications. The document advocates using story maps for product-driven testing at different levels and across perspectives to discover cross-cutting challenges.
This document summarizes a presentation about the mobile security Linux distribution Santoku Linux. It discusses how Santoku Linux was created by modifying Lubuntu to include mobile forensic and security tools from the company viaForensics. Some key tools discussed include AFLogical OSE for Android logical acquisitions, iPhone Backup Analyzer, and utilities for analyzing mobile malware samples. Real-world examples of analyzing the Any.DO task manager app and Korean banking malware are also provided.
Web security-–-everything-we-know-is-wrong-eoin-kearydrewz lin
1) Web application security is often approached incorrectly, focusing too much on annual penetration tests and compliance, rather than ongoing monitoring and prevention through the development process.
2) Many vulnerabilities are introduced through third party libraries and dependencies, which are not properly tested or managed. Continuous testing across the full software supply chain is needed.
3) Not all vulnerabilities are equal - context is important. A risk-based approach should prioritize the most critical issues based on factors like impact, likelihood, and the development environment. Compliance alone does not ensure real security.
The document discusses concepts related to continuous delivery and deployment pipelines. It advocates building quality into software through automated testing and collaboration between developers, testers and operations teams. Continuous delivery aims to make software production-ready at any time by implementing configuration management, continuous integration, and automated testing in a deployment pipeline that provides feedback at every change. This reduces risk and enables frequent, reliable releases that are tied to business needs rather than operational constraints.
The document discusses maintaining high-quality acceptance tests. It provides 5 principles: 1) Treat tests like production code, 2) Interact with the system under test like a user, 3) Continuously curate user journeys, 4) Have collective ownership of acceptance tests, 5) Tests own their own data. The presentation emphasizes that quality is a shared responsibility and tests require ongoing care like production code. Exhaustive story-level testing alone does not lead to maintainable test suites.
There's a recording of this talk at Agile 2012 here: http://www.youtube.com/watch?v=v-L_2y6g5DI
Creating automated end-to-end functional acceptance tests is hard. Maintaining them over time is harder. Some agilistas even claim that the cost outweighs the benefit. In this lecture we present five principles for creating valuable, maintainable acceptance test suites. We discuss practices such as layering acceptance tests to reduce coupling between the test harness, and talk about how teams should be organized in order to efficiently manage acceptance test driven development. The core of the talk discusses how to manage the evolution of acceptance tests by organizing them as scenarios rather than as suites of story tests. Finally we show how to manage data for acceptance tests.
This document discusses the concept of mobile first service design. It notes that last year, smartphones became the new personal computer as their usage surpassed desktop computers. It defines mobile first as designing services with mobile devices as the primary focus from the start. It provides examples of businesses and technologies that have seen success through mobile-first approaches. It discusses challenges like identity, privacy and input methods when designing for mobile and the importance of a minimum viable product approach through experimentation.
JDD 2016 - Joseph W. Yoder - Deliver Fast "With Confidence"PROIDEA
When developing and delivering large, complex systems it can be all too easy to only focus on features and overlook software qualities specific those related to software architecture. Being agile, with its focus on extensive testing and frequent integration, has shown that it can make it easier to deal with issues related to evolving the architectures, specifically when trying keeping the system working while making significant improvements when adding functionality. However, time has shown that various Agile practices are not sufficient to prevent or eliminate Technical Debt which can ultimately affect reliability. It is important to recognize what is core to the architecture and the problem at hand when evolving an architecture. If there is not enough attention on the architecture and code base, ultimately technical debt will creep in to the point where it can become hard to delivery quickly and with confidence.
Two important principle that can help teams deliver more quickly and with confidence is to focus on code quality and delivery size. Small frequently delivery with constant attention to a good code base is crucial to being able to sustain faster delivery with confidence. Often teams evolve to continuous delivery with some limited success, however issues arise when there is not good validation through tests and constant attention to the code quality. Practices that can help keep the code clean or from getting muddier include: Testing, Divide & Conquer, Gentrification, Quarantine, Refactoring, and Craftsmanship. This talk will examine techniques such as Continuous Integration, Continuous Inspection, Continuous Delivery as well as other techniques to pay good attention to code quality allowing teams to delivery more quickly and with confidence.
7 Deadly Sins of Agile Software Test AutomationAdrian Smith
The document outlines 7 deadly sins of automated testing: envy, gluttony, lust, pride, sloth, rage, and greed. It discusses flaws in comparing manual and automated testing, overreliance on commercial tools, focus on user interfaces over architecture, lack of collaboration, poor maintenance, frustration with brittle tests, and attempts to cut costs rather than improve quality. The document advocates for collaboration, technical best practices, and treating tests as critical code.
SpeakerConf: my findings in trying to use this functional programming busines...Phil Calçado
The document summarizes the findings of someone experimenting with functional programming. It discusses whether tests are good for designing pure functions, dealing with impedance between functional and object-oriented code, and how static typing could potentially replace some testing by catching errors. It also mentions potential relationships between category theory and software engineering.
The document discusses building vibrant internal and external communities through an enterprise social media and collaboration framework. It proposes integrating social features and communities into core business processes, and establishing metrics to measure the impact on business objectives like return on investment and knowledge reuse. A case study from Sun Microsystems shows how their collaboration platform improved win rates and margins through increased document reuse.
This document discusses how Etsy enables rapid experimentation through continuous deployment and metrics-driven development. Key points include deploying small code changes frequently using feature flags and ramp-ups, measuring everything with tools like StatsD, optimizing for learning by running many experiments, and gaining confidence to change through quantitative metrics. The goal is to make failures cheap and iterate quickly to find product-market fit.
How to be a Lean Product Developer? @Agile Riga Day 2012Marko Taipale
The document provides guidance for lean product development. It recommends:
1. Validating business ideas through customer development and getting feedback to turn ideas into a series of testable hypotheses rather than guesses.
2. Building software faster using techniques like acceptance test-driven development (ATDD) and just-in-time architecture to minimize waste and inventory in the development process.
3. Measuring key metrics to understand customer needs and prioritize features, determine when requirements are met, and track progress over time.
The document discusses unit testing and functional programming concepts. It provides examples of testing AMQP (Advanced Message Queuing Protocol) code in a functional style by separating pure and impure code. Functions are defined to construct arguments for the queue_declare method in a testable way. This allows testing each part in isolation and combining them to test full functionality.
Building better products requires up-front investment in product planning and strategy. This talk will cover basic User Experience tools and techniques for breaking down a project, planning the architecture, organizing development, and communicating those ideas to colleagues and technical partners. We will cover creative ways to generate ideas and collaborate with your stakeholders. We’ll also introduce you to conceptual tools that will help solve problems visually as well as design activities including sketching and wireframing.
This document discusses how paper prototyping can help founders improve their product's user experience early in the development process. It recommends creating low-fidelity paper prototypes to test with users, identifying issues, and iteratively refining designs based on feedback before implementing interfaces in code. The process of rapid prototyping and testing allows founders to learn what users need through direct observation and make the user experience a priority from the start.
Measuring Web Performance - HighEdWeb EditionDave Olsen
Today, a Web page can be delivered to desktop computers, televisions, or handheld devices like tablets or phones. While a technique like responsive design helps ensure that our websites look good across that spectrum of devices we may forget that we need to make sure that our websites also perform well across that same spectrum. More and more of our users are shifting their Internet usage to these more varied platforms and connection speeds with some moving entirely to mobile Internet. In this session, we’ll look at the tools that can help you understand, measure and improve the performance of your websites and applications. The talk will also discuss how new server-side techniques might help us optimize our front-end performance. Finally, since the best way to test is to have devices in your hand, we’ll discuss some tips for getting your hands on them cheaply. This presentation builds upon Dave Olsen’s “Optimization for Mobile” chapter in Smashing Magazine’s “The Mobile Book.”
The document provides guidance on building quality into software development through defect prevention rather than defect removal. It discusses how the best companies aim to freeze code and test within 10% of the release cycle, rather than leaving 30-50% for "hardening". An effective process matches tests to specifications and code, rather than introducing defects first. It also advocates optimizing throughput over utilization by limiting work, leveling the workload, and shortening deployment cycles.
The document discusses concepts related to user-driven development and lean startups. It advocates for an agile approach focused on delivering minimum viable products, conducting customer development, and employing a build-measure-learn process. This allows teams to collect validated learning from users with minimal effort through iterative improvements and experiments. The goal is to achieve product-market fit by understanding user needs and eliminating non-essential features.
Continuous Deployment involves shipping code as frequently as possible, even multiple times per day. It allows for smaller changes with less risk, faster feedback, and a competitive advantage. To achieve this, companies optimize their deployment process, automate testing and deployments, and measure everything to learn and improve continuously. This approach is enabled by technologies like cloud computing and embraced by companies like Google, Amazon, and Facebook.
This document discusses sandboxing untrusted JavaScript from third parties to improve security. It proposes a two-tier sandbox architecture that uses JavaScript libraries and wrappers, without requiring browser modifications. Untrusted code is executed in an isolated environment defined by policy code, and can only access approved APIs. This approach aims to mediate access between code and the browser securely and efficiently while maintaining compatibility with existing third-party scripts.
This document discusses how HTML5 features can be used for authentication purposes and addresses some security challenges. It describes APIs like local storage, canvas, geolocation, and notifications that could be leveraged for authentication factors like passwords, patterns, and one-time passwords. However, it also notes risks like storing sensitive data on devices, spoofing locations, and notifications not being reliable. The document advocates using HTML5 responsibly and understanding privacy and user behavior when designing authentication solutions.
Owasp advanced mobile-application-code-review-techniques-v0.2drewz lin
The document discusses code review techniques for advanced mobile applications. It begins with an overview of why mobile security is important given the rise in mobile usage. It then discusses different mobile application types and architectures that can be code reviewed, including native, hybrid, and HTML5 applications. The document outlines the goals of mobile application code reviews, such as understanding the application and finding security vulnerabilities. It provides the methodology for conducting code reviews, which includes gaining access to source code, understanding the technology, threat modeling, analyzing the code, and creating automation scripts. Finally, it discusses specific vulnerabilities that may be found in Windows Phone, hybrid, Android, and iOS applications.
The document discusses research conducted by Gregg Ganley and Gavin Black at MITRE in FY13-14 on iOS mobile application security. It describes their work on a tool called iMAS (iOS Mobile Application Security) which aims to provide additional security controls and containment for native iOS applications. iMAS addresses vulnerabilities related to runtime access, device access, application access, data at rest, and threats from app stores/malware. It utilizes techniques like encrypted code modules, forced inlining, secure MDM and more to raise security levels above standard iOS but below a fully customized/rooted mobile device environment. The document outlines the motivation, capabilities and future research directions for the iMAS project.
Defeating xss-and-xsrf-with-my faces-frameworks-steve-wolfdrewz lin
This document discusses how to defeat cross-site scripting (XSS) and cross-site request forgery (XSRF) when using JavaServer Faces (JSF) frameworks. It covers validating user input, encoding output, and protecting view states to prevent XSS, as well as configuring JSF implementations to protect against XSRF by encrypting view states and adding tokens to URLs. The presentation emphasizes testing validation, encoding, and protection in specific JSF implementations since behaviors can differ.
This document summarizes a presentation on defending against CSRF (cross-site request forgery) attacks. It discusses four main design patterns for CSRF defenses: the synchronizer token pattern, double submit cookies, challenge-response systems, and checking the referrer header. It then provides details on implementing these patterns, specifically looking at libraries and features in .NET, .NET MVC, Anticsrf, CSRFGuard, and HDIV that can help implement CSRF tokens and validation. The document covers the tradeoffs of different approaches and considerations for using them effectively on the code and server level.
Chuck willis-owaspbwa-beyond-1.0-app secusa-2013-11-21drewz lin
This document provides an overview of the OWASP Broken Web Applications (OWASP BWA) project. It discusses the background and motivation for the project, describes the current status including what applications are included in the virtual machine, outlines future plans, and solicits feedback to help guide and expand the project. The goal of OWASP BWA is to provide a free, open-source virtual machine containing a variety of intentionally vulnerable web applications to aid in testing tools and techniques for finding and addressing security issues.
This document provides a summary of a presentation by Robert Hansen on the future of browser security. Hansen argues that while browser developers want to improve security and privacy, their companies' business models focused on advertising revenue prohibit them from doing so. He outlines various techniques used by advertisers and browser companies to track users against their preferences. Hansen advocates for technical controls that allow users to opt out of tracking through a "can not track" approach, rather than relying on ineffective "do not track" policies. He concludes by discussing WhiteHat Security's focus on privacy and their plans to add more security and privacy features to their Aviator browser.
Appsec usa2013 js_libinsecurity_stefanodipaoladrewz lin
This document summarizes Stefano di Paola's talk on security issues with JavaScript libraries. It discusses how jQuery's $() method can be considered a "sink" that executes HTML passed to it, including examples of XSS via jQuery selectors and AJAX calls. It also covers problems with JSON parsing regular expressions, AngularJS expression injection, and credentials exposed in URLs. Solutions proposed include validating all input, auditing third-party libraries, and moving away from approaches like eval() that execute untrusted code.
Appsec2013 presentation-dickson final-with_all_final_editsdrewz lin
(1) A study surveyed 600 software developers and found that most did not have a basic understanding of software security concepts, with 73% failing an initial survey and the average score being 59% before training. (2) However, after training, developers' understanding of key concepts increased, with some areas like cross-site scripting seeing a 20 percentage point gain. (3) The study concluded that targeted security training can improve developers' knowledge in the short-term, though retention of this knowledge may require refresher training over time.
This document summarizes Bruno Gonçalves de Oliveira's talk on hacking web file servers for iOS. It introduces Bruno and his background in offensive security and discusses how iOS devices store a lot of information and mobile applications are often poorly designed and vulnerable. It provides examples of vulnerable file storage apps, outlines features and vulnerabilities like lack of encryption, authentication, XSS issues, and path traversal flaws. The document demonstrates exploits like unauthorized access to file systems on jailbroken devices and how to find vulnerable systems through mDNS queries. It concludes that mobile apps are the future but designers still do not prioritize security and there are too many apps for users to vet carefully.
Appsec 2013-krehel-ondrej-forensic-investigations-of-web-exploitationsdrewz lin
This document discusses forensic investigations of web exploitations. It presents a scenario where a web server in a DMZ zone was exploited but logs are unavailable, so network traffic must be analyzed. Wireshark will be used to analyze a PCAP file of recorded traffic to determine what happened and find any traces of commands or malware. The document also provides information on the costs of different types of cyber attacks, how to decode HTTP requests, and discusses tools that can be used for network forensics investigations like Wireshark, tcpdump, and Xplico.
Appsec2013 assurance tagging-robert martindrewz lin
The document discusses engineering software systems to be more secure against attacks. It notes that reducing a system's attack surface alone is not enough, as software and networks are too complex and it is impossible to know all vulnerabilities. It then discusses characteristics of advanced persistent threats, including that the initial attack may go unnoticed and adversaries cannot be fully kept out. Finally, it argues that taking a threat-driven perspective beyond just operational defense can help balance mitigation with detection and response.
The document summarizes a presentation on vulnerabilities found in SCADA systems between 2009-2013. It analyzed vulnerabilities by component, with the majority (66%) found in communication components like Modbus and DNP3 protocols. Examples of vulnerabilities are described for several devices. Real-world issues with SCADA systems are discussed like lack of authentication and patching. Recommendations are provided like auditing SCADA networks, implementing secure protocols and password policies, and keeping systems updated.
This 3-page document discusses the real-world challenges of implementing an agile software development lifecycle (SDLC) approach from the perspectives of Chris Eng and Ryan O'Boyle. It was presented at the OWASP AppSec USA conference on November 20, 2013 and focuses on practical lessons learned and best practices for incorporating security throughout an agile SDLC.
This document outlines a presentation given by Simón Roses Femerling on software security verification tools. It discusses BinSecSweeper, an open source tool created by VulnEx to scan binaries and check that security best practices were followed in development. The presentation covers using BinSecSweeper to verify in-house software, assess a company's software security posture, and compare the security of popular browsers. Examples of plugin checks and reports generated by BinSecSweeper are also provided.
1. Continuous Delivery
@jezhumble
#Agile2012, 15 August 2012
http://thoughtworks-studios.com/
Thursday, August 16, 12
2. agile 101
"Agile" team
Analysis + Design Centralized QA IT Operations
Development Integration + QA Release and operation
Customer Testing + Showcase
Iteration 0 1 2 3 4
The "last mile"
Thursday, August 16, 12
3. web 2.0
disrupting traditional businesses
http://code.flickr.com/
Thursday, August 16, 12
4. releasing frequently
build the right thing
Customer
developent
Agile product
development
Eric Ries, “The Lean Startup” http://bit.ly/8ZoX5F
Thursday, August 16, 12
5. innovate
You can't just ask
customers what
they want and then
try to give that to
them.
By the time you get
it built, they'll want
something new.
Steve Jobs
Thursday, August 16, 12
6. scientific method
Ideas
create hypothesis Learn Build
deliver minimum
viable product
Data Code
get feedback Measure
(repeat)
Eric Ries, “The Lean Startup” http://bit.ly/8ZoX5F
Thursday, August 16, 12
7. ask this question
“How long would it take your
organization to deploy a change that
involved just one single line of code? Do
you do this on a repeatable, reliable
basis?”
Mary and Tom Poppendieck, Implementing Lean Software Development, p59.
Thursday, August 16, 12
8. releasing frequently
build the right thing
reduce risk of release
John Allspaw: “Ops Metametrics” http://slidesha.re/dsSZIr
Thursday, August 16, 12
11. releasing frequently
build the right thing
reduce risk of release
real project progress
Thursday, August 16, 12
12. agile manifesto
Our highest priority is to satisfy
the customer through early and
continuous delivery of
valuable software
Thursday, August 16, 12
13. production-ready software
Fast, automated feedback on
the production readiness of
your applications every time
there is a change - to code,
infrastructure, or configuration
Thursday, August 16, 12
14. continuous delivery
Software always production ready
Releases tied to business needs, not
operational constraints
Thursday, August 16, 12
15. continuous delivery
automation
patterns and practices
collaboration
Thursday, August 16, 12
17. Local
Develop
Workstation
Mainline Server
Build
pull
Build Build
✔
Done!
push
Thursday, August 16, 12
18. Local
Develop
Workstation
Everyone Commits
Mainline Server
Build
To the pull
Mainline
Build
Every Day
Build
✔
Done!
push
Thursday, August 16, 12
19. build quality in
“Cease dependence on
mass inspection to
achieve quality.
Improve the process
and build quality into
the product in the first
place”
W. Edwards Deming
Thursday, August 16, 12
20. different kinds of testing
Business facing
AUTOMATED MANUAL
Showcases
Support programming
Functional acceptance
Usability testing
tests
Critique project
Exploratory testing
Unit tests Non-functional
Integration tests acceptance tests
System tests (performance, scaling, ...)
AUTOMATED MANUAL / AUTOMATED
Technology facing
Diagram invented by Brian Marick
Thursday, August 16, 12
21. deployment pipeline
an automated implementation of your
system’s build, deploy, test, release process
visibility
feedback
control
Thursday, August 16, 12
22. deployment pipeline
Delivery team Version control Build & unit Automated User acceptance Release
tests acceptance tests tests
Check in
Trigger
Feedback
Check in
Trigger
Feedback Trigger
Feedback
Check in
Trigger
Feedback Trigger
Feedback Approval
Feedback Approval
Thursday, August 16, 12
25. reducing release risk
automate provisioning and deployment
ensure devs, testers and ops collaborate
throughout
Thursday, August 16, 12
26. reducing release risk
devops
incrementalism
decoupling deployment and release
Thursday, August 16, 12
27. devops
culture
automation
measurement
sharing
Thursday, August 16, 12
28. feature toggles
blue-green deployments
canary releases
low risk releases
are incremental
dark launching
production immune system
Thursday, August 16, 12
38. canary releasing
Reduce risk of release
Multi-variant testing
Performance testing
Thursday, August 16, 12
39. immune system
what if someone replaced your
“buy” button with spacer.gif?
T cells http://www.flickr.com/photos/gehealthcare/3326186490/
Thursday, August 16, 12
45. enterprise governance
risk management
SOX, ITIL, COBIT
segregation of duties
change management
auditing and compliance
Thursday, August 16, 12
46. people are the key
Get everyone together at the beginning
Keep meeting
Make it easy for everyone to see what’s
happening
Continuous improvement (kaizen)
Thursday, August 16, 12