Critical and Design Thinking

Critical & Design Thinking aims to build shared understanding, collective knowledge & sensemaking through a community of professionals from different backgrounds and horizons.

Refer to these useful resources and books at

https://library.designcriticalthinking.com/library/books

Enterprise Design Patterns (Intersection Group Book) is at

https://library.designcriticalthinking.com/library/books/enterprise-design-patterns-intersection-group-book

DevSecOps - Reference Architecture and Recommendations

DevSecOps - Reference Architecture and Recommendations

What is DevSecOps?

DevSecOps is the philosophy of integrating security practices within the DevOps pipeline, ensuring two seemingly opposed goals: speed of delivery and secure code. Critical security issues are dealt with as they become apparent at almost all stages of the SDLC process, not just after a threat or compromise has occurred. It’s not only about additional tools that automate tasks, but also about the mentality of your developers.

Recommendations for a comprehensive DevSecOps?

1. IDE Plugins — IDE extensions that can work like spellcheck and help to avoid basic mistakes at the earliest stage of coding (IDE is a place/program where devs write their code for those who don’t know). The most popular ones are probably DevSkim, JFrog Eclipse, and Snyk.
2. Pre-Commit Hooks — Tools from this category prevent you from committing sensitive information like credentials into your code management platform. There are some open-source options available, like git-hound, git-secrets, and repo-supervisor.
3. Secrets Management Tools allow you to control which service has access to what password specifically. Big players like AWS, Microsoft, and Google have their solutions in this space, but you should use cloud-provider-agnostic ones if you have multi-cloud or hybrid-cloud in place.
4. Static Application Security Testing (SAST) is about checking source-code (when the app is not running). There are many free & commercial tools in the space (see here), as the category is over a decade old. Unfortunately, they often result in a lot of false positives, and can’t be applied to all coding languages. What’s worse is that they take hours (or even days) to run, so the best practice is to do incremental code tests during the weekdays and scan the whole code during the weekend.
5. Source Composition Analysis (SCA) tools are straightforward — they look at libraries that you use in your project and flag the ones with known vulnerabilities. There are dozens of them on the market, and they are sometimes offered as a feature of different products — e.g. GitHub.
6. Dynamic Application Security Testing (DAST) is the next one in the security chain, and the first one testing running applications (not the source code as SAST — you can read about other differences here). It provides less false positives than SAST but is similarly time-consuming.
7. Interactive Application Security Testing (IAST) combines SAST and DAST elements by placing an agent inside the application and performing real-time analysis anywhere in the development process. As a result, the test covers both the source code and all the other external elements like libraries and APIs (this wasn’t possible with SAST or DAST, so the outcomes are more accurate). However, this kind of testing can have an adverse impact on the performance of the app.
8. Secure infrastructure as code — As containers are gaining popularity, they become an object of interest for malware producers. Therefore you need to scan Docker images that you download from public repositories, and tools like Clair will highlight any potential vulnerabilities.
9. Compliance as code tools will turn your compliance rules and policy requirements into automated tests. To make it possible your devs need to translate human-readable rules received from non-tech people into code, and compliance-as-a-code tools should do the rest (point out where you are breaking the rules or block updates if they are not in line with your policies).
10. Runtime application self-protection (RASP) allows applications to run continuous security checks and react to attacks in real-time by getting rid of the attacker (e.g. closing his session) and alerting your team about the attack. Similarly to IAST, it can hurt app performance. It’s 4th testing category that I show in the pipeline (after SAST, DAST, and IAST) and you should have at least two of them in your stack.
11. Web Application Firewall (WAF) lets you define specific network rules for a web application and filter, monitor, and block HTTP traffic to and from a web service when it corresponds to known patterns of attacks like, e.g. SQL injection. All big cloud providers like Google, AWS and Microsoft have got their WAF, but there are also specialised companies like Cloudflare, Imperva and Wallarm, for example.
12. Monitoring tools — as mentioned in my DevOps guide, monitoring is a crucial part of the DevOps manifesto. DevSecOps takes it to the next level and covers not only things like downtime, but also security threats.
13. Chaos engineering. Tools from this category allow you to test your app under different scenarios and patch your holes before problems emerge. “Breaking things on purpose is preferable to be surprised when things break” as said by Mathias Lafeldt from Gremlin.
14. Vulnerability management — these tools help you identify the holes in your security systems. They classify weaknesses by the potential impact of malicious attacks taking advantage of them so that you can focus on fixing the most dangerous ones. Some of the tools might come with addons automatically fixing found bugs. This category is full of open source solutions, and here you can find the top 20.

Reference Architectures of DevSecOps?

Refer: https://cdn2.hubspot.net/hubfs/4132678/Resources/DevSecOps%20Reference%20Architectures%20-%20March%202018.pdf

References:

https://medium.com/inside-inovo/devsecops-explained-venture-capital-perspective-cb5593c85b4e

Building vs. Buying In-App Chat

Building vs. Buying In-App Chat: The Ultimate Guide to Weighing Cost, Risk, & Other Product Roadmap Decisions

The choice between in-house chat development and today’s vendor solutions is highly consequential. The following considerations belong at the core of any feasibility analysis, cost approximation, or product roadmap.

Here are the high-level build vs. buy factors every product team should examine: 

• Evaluate Your App’s Goals, Priorities, & Core Value Prop 
• Weigh Dev Team Opportunity Cost 
• Compare Costs: Estimating the Financial Investment to Build or Buy Chat 
• Cost to Develop Chat Functionality In House 
• Calculating Initial Chat Development Cost 
• Calculating Maintenance, Improvement, & Scaling Costs 
• Estimate the Cost to Buy an In-App Chat Solution 
• In-App Chat as a Capital vs. Operational Expenditure 
• Evaluate Time to Market & Time to Value 
• Competitive Advantage & Time to Market 
• Select Critical Chat Features: Best-of-Breed vs. MVP 
• Core In-App Chat Features for an MVP Offering 
• Advanced Chat Features 
• Real-World Example: Feature Depth & Reliability with TaskRabbit 
• Identify Risks Involved with Building vs. Buying Chat 
• Security & Compliance 
• Data & Storage Ownership 
• Decision Ownership 
• Scalability 
• Reliability & Performance 
• Technical Debt 
• Cross-Platform Development 
• Vendor Lock-In 
• Make the Final Build vs. Buy Decision
  

The decision to build or buy chat functionality can’t be made lightly. It plays a direct role in your product’s ability to delight users and solve their problems, driving engagement and retention. The decision also has significant financial implications, with an impact on budgeting and prioritization of engineering resources. It’s a decision that must be made with your organization’s unique value proposition, customer base, goals, and requirements in mind. Paired with these factors, the analysis above should help to produce an exhaustive list of pros and cons of building or buying in-app chat functionality, supporting a carefully informed decision. 

For many organizations, the advantages gained in up-front cost, total cost, time to market, and feature depth will make a chat API or SDK solution the logical choice. Still, for others with enough cash and development resources available or with a completely revolutionary vision for how chat looks and functions, in-house development may be worth the investment.

Reference: https://getstream.io/blog/build-vs-buy-chat/

Book Summary - Scrum: The Art Of Doing Twice The Work In Half The Time

Book Summary - Scrum: The Art Of Doing Twice The Work In Half The Time

My key takeaways:

• Scrum needs involvement and alignment from all stakeholders to bring value to the project as early as possible
• Scrum is based on the people they work with; and also it completely varies between the pods and scrum teams
• Clearly define the roles of the team, Scrum Master, Product Manager, Product Owner, Development team along with the QA, etc
• Product development also follows the Pareto Principle: 20% of the requirements represent 80% of the product's value. Thus, the objective is to prioritize the items for the current sprint
• MVP and delivering smaller chunks of product backlog without no major risk to the current production capabilities is the success of scrum
• PDCA cycle (Plan, Do, Check and Act)
• Have a clear way of defining DoR (Definition of Ready) and DoD (Definition of Done) for your scrum team
• Follow your suited sprint ceremonies to get the most out of your scrum outcomes, such as Sprint planning, Sprint, Daily scrum meeting, Sprint Review, and Sprint retrospective
• How fast the daily raised impediments during the scrum standup are getting resolved would define the agility of your scrum team
• Make sure to provide a clear vision, and refine the product backlog so that the sprint backlog is very clear to the scrum team

Reference:

http://amazon.com/Scrum-Doing-Twice-Work-Half/dp/038534645X