The cybersecurity unicorn reduced losses by 33% to $176 million, with its revenue reaching $220 million.

Snyk cuts losses by a third, boosts revenue by 50%, as it prepares for IPO | Ctech

In today’s digital age, our children are growing up in a world that is vastly different from the one we knew as kids. With the internet and video games becoming an integral part of their lives, the responsibilities of parents

The Imperative Role Parents Play in Ensuring Their Children’s Safety While Navigating the Digital Landscape

Venkat Raghavan is the founder and CEO of Stack Identity, a Bay area startup. He is an operator, builder, and entrepreneur with over 25 years of enterprise security software experience spanning big tech and start-ups. Venkat has held a variety of senior ...

Venkat Raghavan

Snyk CEO Peter McKay spoke about why so many security startups need an acquisition soon, along with Snyk’s IPO goal and GenAI-created code.

Snyk CEO Peter McKay: Startups Looking To Get Acquired ‘Dramatically’ Increasing

The National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA), along with... The post How to Overcome the Three Main MFA Challenges Identified by NSA and CISA appeared first on Axiad.

How to Overcome the Three Main MFA Challenges Identified by NSA and CISA

Black Hat, the producer of the cybersecurity industry’s most established and in-depth security events, today announced the release of its content line

Black Hat Announces Content Lineup for Black Hat Europe 2023

Nightfall AI, the leader in cloud Data Leak Prevention (cloud DLP), today announced a partnership with Snyk, a leading developer security provider, to offer developers AI-powered secrets-scanning capabilities.

Nightfall AI and Snyk Partner to Offer Developers AI-Powered Secrets Scanning

Cloud data protection startup Nightfall AI today announced a new partnership with cybersecurity company Snyk Ltd. to provide developers with artificial intelligence-powered secrets scanning capabilities.

Nightfall AI and Snyk partner to provide AI-powered secrets scanning to developers

Each year, the costs of data breaches continue to rise, and there haven’t been many signs that this trend will slow down any time soon. In 2014, the average data breach cost companies $3.5 million. Fast forward to 2023,

23andMe experiences data breach; FBI issues warning over scheme targeting the elderly

Snyk

snyk

In November of last year, — a security company that finds, fixes and monitors known vulnerabilities in Node.js and Ruby on Rails applications — joined the Node.js Foundation. Snyk We recently sat down with co-founder and CEO of Snyk, Guy Podjarny, to talk to him a bit more about Snyk, creating better security for the larger Node.js package ecosystem, and why Snyk joined the Node.js Foundation. Q: Snyk is a fairly new company, tell us a little bit more about the company’s background? A: Snyk adds a layer of security to open source code, notably npm. We let you easily find and fix known vulnerabilities in your dependencies, and integrate seamlessly into your continuous workflow to prevent adding new vulnerable packages. Lastly, we track your dependencies and alert you when new vulnerabilities are found in them, helping you respond faster than attackers would. Snyk was built on the belief that security must be built into your development process. Security must become a natural part of the dev process, and that with the right tools this aspiration can become reality. Our team combines dev tooling and UX expertise with deep cyber security knowledge, and we’re committed to building friendly and powerful tools, used by developers daily to stay secure without slowing down. Last but not least, we believe in inclusive security. We do our best to be builders and offer constructive advice instead of fear mongering, bringing much of the DevOps culture into security. Q: Why is security in the package ecosystem so important? A: The transformation npm and other package managers are bringing to the world of development is both amazing and complicated. On one hand, the power of crowd-sourced open source packages is a game changer. We believe it will disrupt the development world just like Wikipedia, eBay and Airbnb disrupted their respective industry. Even the richest SDK and broadest built-in library pales in comparison to a tiny package management ecosystem, and nothing compares to the productivity boost you get from building on the power of the entire web. On the other hand, would you bet your company on every Wikipedia article being entirely accurate and every single author a good Samaritan? Unfortunately, the current use of npm (and other open source package platforms) is doing just that. Organizations, big and small, blindly consume hundreds of packages, pulling them into their code and running them with little or no scrutiny. Doing so implicitly trusts these packages, along with all of their contributors, with the application’s secrets and the customer data it has access to. While most open source contributors are capable and good willed, mistakes do happen and bad actors do exist. Without a way to scrutinize our use of open source packages at scale, accidents can happen. Q: What is your philosophy around approaching security, especially for something as vast at the Node.js package ecosystem? We believe automated & developer-friendly security tools, operated by the dev and ops teams, are the only way to keep Node.js applications secure. This perspective combines two core beliefs: First and foremost, we believe security is everyone’s responsibility. Within a company, expecting a small and outnumbered team to keep up with a fast changing Node.js application simply doesn’t work. As a result, either the dev team needs to be slowed down, or the security team doesn’t keep up; both bad outcomes. We need the application team itself, including dev and ops, to take responsibility for shipping secure applications. Within the Node.js ecosystem, those who need to step up are open source consumers. Unlike commercial software, when using OSS you’re not entitled to anything. You’re getting great value for free, and you need to accept your responsibility in knowing what you’re using and keeping it secure. Since consumers (often businesses) typically have more security expertise in the first place, it’s also their responsibility to contribute security insights and findings back to the open source authors and the broader community. Good security requires good developer tools. Security is a vast and complex topic. While we must all do our share, we can’t expect every developer to become a security expert. When we don’t have expertise, we revert to tools that can help give us the knowledge we need at the right time. To get security spread throughout the developer and Node.js ecosystem, we need easy-to-use tools that can surface security concerns and guide non-experts to remediate them. These tools should be built for and primarily used by developers, not security professionals, requiring them to be attuned to how developers work. Q: Do you have any best practices or suggestions for how module developer can create safer packages? It may sound obvious, but the first step is to care about security. Many package developers focus on the functionality they make available, and don’t stop to consider the security implications of different decisions they make. Caring about security is hard, because you don’t have anything to show for it once done, but it’s important nonetheless. When you care, the second step is to document your security considerations and decisions. Create a Security.md in your repo, listing the security questions you considered and how you have (or haven’t) addressed them. These lists are a great way to organize your thoughts and next steps, and they help contributors participate in adding or answering questions. They also help educate consumers as to the security aspects of your package. Last but not least, use the security tools that apply to you. Q: How do you think we create more security in the Node.js package module community? I believe there are three things we can do: . Security is naturally invisible, and it’s easy to simply not think about it, until something blows up in a big way. We need to make sure security concerns and best practices are a natural and recurring part of every Node.js event, blog and other educational events. Discuss security more . If security isn’t easy to do, it won’t get done. I’m a huge believer in ensuring security tools are easy to find and use, and we put a lot of emphasis on user experience and ease of use at Snyk. Better tooling . You typically hear about security failures, like breaches and hacks, but good security rarely gets a mention. Whenever possible, we should try to applaud and point out those who do security well. At Snyk we have a GitHub badge showing how many vulnerable dependencies you have. This is a great way to tell the world you care about security and are addressing it, and that they should do so too. Celebrate successes Q: Why did you join the Node.js Foundation? How does that align with Snyk’s objectives/common goal? We joined the Foundation to ensure security stays top of mind, and to help contribute our expertise to keeping Node.js and its community secure. Snyk’s mission is to help developers use open source and stay secure, and this mission cannot succeed without keeping the open source core secure. In addition, we believe the best path to security is to make it the default — make it easier to be secure than to be insecure. We hope to drive and influence decisions that make Node.js secure out of the box, which will have big security implications for the entire ecosystem. Q: What are you most excited about in the coming year? There is a lot to be excited about this year, but at the top of the list is probably serverless (Function-as-a-Service). This novel approach to managing your infrastructure is exciting by itself, and is naturally attuned to how Node.js and npm work, so it’s no surprise Node.js is thriving in this space. Serverless raises very interesting questions and challenges regarding npm package security, and whether they should be monitored in the CI/CD process or by monitoring the platform itself. We’ve recently launched an exciting new product that lets you monitor for vulnerable packages directly on Lambda & Heroku, which I believe has great promise to how we perceive open source packages and we can keep them secure.

Q&A with Snyk on security, npm and the Node.js Foundation

The Top AI Tools for Web Development

Google Cloud x Gemini: Accomplish More in the Cloud with Generative AI

Helloooooooo! Hope you're doing great! This is SMY! 👋 Let's jump right in 🚀 Part 1: Our First MVP Part 2: Structure and API Part 3: Making Test Apps Part 4: Publishing to npm Part 5: CDN for Browsers This is Part 4 of our SDK development series where we will publish our SDK Contents: ⚡ Creating an NPM account
⚡ Publishing to NPM, semantic versioning, and LICENSE Step 1: Creating an NPM Account Head over to https://www.npmjs.com, and create an account. Step 2: Publish In the terminal, write: npm login After following the login steps, write: npm publish This can fail due to duplicate package names or wrong configuration in package.json Your package.json should look like the following: {
  "name": "ts-lib-template-starter",
  "version": "1.0.0",
  "description": "SDK development tutorial",
  "main": "./src/index.ts",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "tsup ./src/index.ts --watch"
  },
  "type": "module",
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@types/node": "^20.14.8",
    "tsup": "^8.1.0",
    "typescript": "^5.5.2"
  }
} Congrats; you just published your first SDK to NPM 🎉🥳 🚀🚀🚀 Step 3: Semantic Versioning When publishing a library, it is good to keep versioning in check. Versioning helps the developer integrate the code to get an idea of what update happened to the SDK. Furthermore, the right versioning will help package managers to update to the level as it is mentioned in their package.json. To help developers who rely on your code, we recommend starting your package version at 1.0.0 and incrementing as follows: Code status

Stage

Rule

Example version



First release

New product

Start with 1.0.0

1.0.0



Backward-compatible bug fixes

Patch release

Increment the third digit

1.0.1



Backward-compatible new features

Minor release

Increment the middle, digit and reset the last digit to zero

1.1.0



Changes that break backward compatibility

Major release

Increment the first digit and reset the middle and last digits to zero

2.0.0 Learn more about semantic versioning here: https://docs.npmjs.com/about-semantic-versioning Step 4: LICENSE Specify a license for your package so that people know how they are permitted to use it, and any restrictions you're placing on it. source: https://snyk.io/learn/open-source-licenses/ For example, this SDK is open for distribution and modifying the code so I would use MIT as LICENSE. In package.json "license": "MIT" Learn more about various types of LICENCES here: https://snyk.io/learn/open-source-licenses/ Wrapping Up: We Just completed the steps to publish our SDK. Head over to Part 5 where we will make a CDN for browsers 🚀 ..... Now, you're equipped with the knowledge to publish your own SDK. Happy coding! 🚀 That's it, folks! hope it was a good read for you. Thank you! ✨ 👉 Follow me GitHub LinkedIn Helloooooooo! Helloooooooo! Hope you're doing great! This is SMY! 👋 Let's jump right in 🚀 Part 1: Our First MVP Part 1: Our First MVP Part 2: Structure and API Part 2: Structure and API Part 3: Making Test Apps Part 3: Making Test Apps Part 4: Publishing to npm Part 4: Publishing to npm Part 5: CDN for Browsers Part 5: CDN for Browsers This is Part 4 of our SDK development series where we will publish our SDK Contents: ⚡ Creating an NPM account ⚡ Publishing to NPM, semantic versioning, and LICENSE ⚡ Creating an NPM account Creating an NPM account ⚡ Publishing to NPM, semantic versioning, and LICENSE Publishing to NPM, semantic versioning, and LICENSE Step 1: Creating an NPM Account Head over to https://www.npmjs.com , and create an account. https://www.npmjs.com Step 2: Publish In the terminal, write: npm login npm login After following the login steps, write: npm publish npm publish This can fail due to duplicate package names or wrong configuration in package.json package.json Your package.json should look like the following: package.json {
  "name": "ts-lib-template-starter",
  "version": "1.0.0",
  "description": "SDK development tutorial",
  "main": "./src/index.ts",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "tsup ./src/index.ts --watch"
  },
  "type": "module",
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@types/node": "^20.14.8",
    "tsup": "^8.1.0",
    "typescript": "^5.5.2"
  }
} {
  "name": "ts-lib-template-starter",
  "version": "1.0.0",
  "description": "SDK development tutorial",
  "main": "./src/index.ts",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "build": "tsup ./src/index.ts --watch"
  },
  "type": "module",
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@types/node": "^20.14.8",
    "tsup": "^8.1.0",
    "typescript": "^5.5.2"
  }
} Congrats; you just published your first SDK to NPM 🎉🥳 🚀🚀🚀 Step 3: Semantic Versioning When publishing a library, it is good to keep versioning in check. Versioning helps the developer integrate the code to get an idea of what update happened to the SDK. Furthermore, the right versioning will help package managers to update to the level as it is mentioned in their package.json . package.json To help developers who rely on your code, we recommend starting your package version at 1.0.0 and incrementing as follows: 1.0.0 Code status

Stage

Rule

Example version



First release

New product

Start with 1.0.0

1.0.0



Backward-compatible bug fixes

Patch release

Increment the third digit

1.0.1



Backward-compatible new features

Minor release

Increment the middle, digit and reset the last digit to zero

1.1.0



Changes that break backward compatibility

Major release

Increment the first digit and reset the middle and last digits to zero

2.0.0 Code status

Stage

Rule

Example version First release

New product

Start with 1.0.0

1.0.0 Backward-compatible bug fixes

Patch release

Increment the third digit

1.0.1 Backward-compatible new features

Minor release

Increment the middle, digit and reset the last digit to zero

1.1.0 Changes that break backward compatibility

Major release

Increment the first digit and reset the middle and last digits to zero

2.0.0 Code status Stage Rule Example version Code status Code status Code status Stage Stage Stage Rule Rule Rule Example version Example version Example version First release New product Start with 1.0.0 1.0.0 First release First release New product New product Start with 1.0.0 Start with 1.0.0 1.0.0 1.0.0 Backward-compatible bug fixes Patch release Increment the third digit 1.0.1 Backward-compatible bug fixes Backward-compatible bug fixes Patch release Patch release Increment the third digit Increment the third digit 1.0.1 1.0.1 Backward-compatible new features Minor release Increment the middle, digit and reset the last digit to zero 1.1.0 Backward-compatible new features Backward-compatible new features Minor release Minor release Increment the middle, digit and reset the last digit to zero Increment the middle, digit and reset the last digit to zero 1.1.0 1.1.0 Changes that break backward compatibility Major release Increment the first digit and reset the middle and last digits to zero 2.0.0 Changes that break backward compatibility Changes that break backward compatibility Major release Major release Increment the first digit and reset the middle and last digits to zero Increment the first digit and reset the middle and last digits to zero 2.0.0 2.0.0 Learn more about semantic versioning here: https://docs.npmjs.com/about-semantic-versioning https://docs.npmjs.com/about-semantic-versioning Step 4: LICENSE Specify a license for your package so that people know how they are permitted to use it, and any restrictions you're placing on it. source: https://snyk.io/learn/open-source-licenses/ https://snyk.io/learn/open-source-licenses/ For example, this SDK is open for distribution and modifying the code so I would use MIT as LICENSE. In package.json package.json "license": "MIT" "license": "MIT" Learn more about various types of LICENCES here: https://snyk.io/learn/open-source-licenses/ https://snyk.io/learn/open-source-licenses/ Wrapping Up: We Just completed the steps to publish our SDK. Head over to Part 5 where we will make a CDN for browsers 🚀 ..... Now, you're equipped with the knowledge to publish your own SDK. Happy coding! 🚀 That's it, folks! hope it was a good read for you. Thank you! ✨ 👉 Follow me GitHub GitHub LinkedIn LinkedIn

A 5-Year-Old Could Follow This TypeScript SDK Development Guide ~ Part 4: Publishing to NPM

When I think about technical debt, I still remember the first application I created that made me realize the consequences of an unsuitable architecture. It happened back in the late 1990s, when I was first getting started as a consultant. The client had requested use of the Lotus Notes platform to build a procurement system for their customers. Using the Lotus Notes client and a custom application, end-users could make requests that would be tracked by the application and fulfilled by the product owner’s team. In theory, it was a really cool idea – especially since web-developed applications were not prevalent and everyone used Lotus Notes on a daily basis. The core problem is that the data was very relational in design – and Lotus Notes was not a relational database. The solution’s design required schema management within every Lotus Notes document and leaned on a series of multi-value fields to simulate the relationships between data attributes. It was a mess. A great deal of logic in the Lotus Notes application would not have been required if a better platform had been recommended. The source code was complicated to support. Enhancements to the data structure resulted in major refactoring of the underlying code – not to mention running server-based jobs to convert the existing data. Don’t get me started on the effort behind report creation. Since I was early in my career, I have focused on providing a solution that the client wanted rather than trying to offer a better solution. This was certainly a lesson I learned early in my career, but in the years since that project, I’ve come to realize that the consequence of architectural technical debt is an unfortunate reality we all face. Let’s explore the concept of architecture tech debt a little more at a macro level. Architectural Tech Debt (ATD) The Architectural Technical Debt (ATD) Library at Carnegie Mellon University provides the following definition.) of ATD: Architectural technical debt is a design or construction approach that's expedient in the short term, but that creates a technical context in which the same work requires architectural rework and costs more to do later than it would cost to do now (including increased cost over time). In the “Quick Answer: How to Manage Architecture Technical Debt” (published 09/22/2023), Gartner Group defines ATD as follows: Architecture technical debt is that type of technical debt that is caused by architectural drift, suboptimal architectural decisions, violations of defined target product architecture and established industry architectural best practices, and architecture trade-offs made for faster software delivery. In both cases, benefits that often yield short-term celebrations can be met with long-term challenges. This is similar to my Lotus Notes example mentioned in the introduction. To further complicate matters, tooling to help identify and manage tech debt for software architecture has been missing in comparison to the other aspects of software development: For code quality, observability, and SCA, proven tooling exists with products like Sonarqube, Datadog, New Relic, GitHub, and Snyk. However, the software architecture segment has lagged behind without any proven solutions. This is unfortunate, given the fact that ATD is consistently the largest – and most damaging – type of technical debt, as found in the “Measure It? Manage It? Ignore It? Software Practitioners and Technical Debt” 2015 study published by Carnegie Mellon. The following illustration summarizes Figure 4 from that report, concluding that bad architecture choices were the clear leader in sources of technical debt. If not managed, ATD can continue to grow over time at an increasing rate, as demonstrated in this simple illustration: Without mitigation, architecture debt will eventually reach a breaking point for the underlying solution being measured. Managing ATD Before we can manage ATD, we must first understand the problem. Desmond Tutu once wisely said, “There is only one way to eat an elephant: a bite at a time.” The shift-left approach embraces the concept of moving a given aspect closer to the beginning than at the end of a lifecycle. This concept gained popularity with shift-left for testing, where the test phase was moved to a part of the development process and not a separate event to be completed after development was finished. Shift-left can be implemented in two different ways in managing ATD: Shift-left for resiliency — identifying sources that have an impact on resiliency and then fixing them before they manifest in performance.
Shift-left for security — detect and mitigate security issues during the development lifecycle. Just like shift-left for testing, a prioritized focus on resilience and security during the development phase will reduce the potential for unexpected incidents. Architectural observability Architectural observability gives engineering teams the ability to incrementally address architectural drift within their services at a macro level. In fact, the Wall Street Journal reported the cost to fix technical debt at $1.52 trillion earlier this year in “The Invisible $1.52 Trillion Problem: Clunky Old Software,” article. To be successful, engineering leadership must be in full alignment with the following organizational objectives: Resiliency — to recover swiftly from unexpected incidents.
Scalability — to scale appropriately with customer demand.
Velocity — to deliver features and enhancements inline with product expectations.
Cloud Suitability — transforming legacy solutions into efficient cloud-native service offerings. I recently discovered vFunction’s AI-driven architectural observability platform, which is focused on the following deliverables: Discover the real architecture of solutions via static and dynamic analysis.
Prevent architecture drift via real-time views of how services are evolving.
Increase resiliency of applications via the elimination of unnecessary dependencies and improvements between application domains and their associated resources.
Manage and remediate tech debt via AI-driven observability. Additionally, the vFunction platform provides the side-benefit of providing a migration path to transform from monoliths to cloud-native solutions. Once teams have modernized their platforms, they can continuously observe them for ongoing drift. If companies already have microservices, they can use vFunction to detect complexity in distributed applications and address dependencies that impact resiliency and scalability. In either case, once implemented, engineering teams can mitigate ATD well before reaching the breaking point. In the illustration above, engineering teams are able to mitigate technical debt as a part of each release,due to the implementation of the vFunction platform and an underlying shift-left approach. Conclusion My readers may recall that I have been focused on the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester The vFunction platform adheres to my mission statement by helping engineering teams employ a shift-left approach to the resiliency and security of their services at a macro level. This is an important distinction because without such tooling, teams are likely to mitigate at a micro level, resolving tech debt that doesn’t really matter from an organizational perspective. When I think back to that application that made me realize the challenges with tech debt, I can’t help but think about how that solution yielded more issues than it did benefits with each feature that was introduced. Certainly, the use of shift-left for resiliency alone would have helped surface issues with the underlying architecture at a point where the cost of considering alternatives would be feasible. If you are interested in learning more about the vFunction solution, you can read more about them here. Have a really great day! When I think about technical debt, I still remember the first application I created that made me realize the consequences of an unsuitable architecture. It happened back in the late 1990s, when I was first getting started as a consultant. The client had requested use of the Lotus Notes platform to build a procurement system for their customers. Using the Lotus Notes client and a custom application, end-users could make requests that would be tracked by the application and fulfilled by the product owner’s team. In theory, it was a really cool idea – especially since web-developed applications were not prevalent and everyone used Lotus Notes on a daily basis. Lotus Notes The core problem is that the data was very relational in design – and Lotus Notes was not a relational database. The solution’s design required schema management within every Lotus Notes document and leaned on a series of multi-value fields to simulate the relationships between data attributes. It was a mess. A great deal of logic in the Lotus Notes application would not have been required if a better platform had been recommended. The source code was complicated to support. Enhancements to the data structure resulted in major refactoring of the underlying code – not to mention running server-based jobs to convert the existing data. Don’t get me started on the effort behind report creation. Since I was early in my career, I have focused on providing a solution that the client wanted rather than trying to offer a better solution. This was certainly a lesson I learned early in my career, but in the years since that project, I’ve come to realize that the consequence of architectural technical debt is an unfortunate reality we all face. Let’s explore the concept of architecture tech debt a little more at a macro level. Architectural Tech Debt (ATD) The Architectural Technical Debt (ATD) Library at Carnegie Mellon University provides the following definition .) of ATD: definition Architectural technical debt is a design or construction approach that's expedient in the short term, but that creates a technical context in which the same work requires architectural rework and costs more to do later than it would cost to do now (including increased cost over time). Architectural technical debt is a design or construction approach that's expedient in the short term, but that creates a technical context in which the same work requires architectural rework and costs more to do later than it would cost to do now (including increased cost over time). In the “Quick Answer: How to Manage Architecture Technical Debt” (published 09/22/2023), Gartner Group defines ATD as follows: Architecture technical debt is that type of technical debt that is caused by architectural drift, suboptimal architectural decisions, violations of defined target product architecture and established industry architectural best practices, and architecture trade-offs made for faster software delivery. Architecture technical debt is that type of technical debt that is caused by architectural drift, suboptimal architectural decisions, violations of defined target product architecture and established industry architectural best practices, and architecture trade-offs made for faster software delivery. In both cases, benefits that often yield short-term celebrations can be met with long-term challenges. This is similar to my Lotus Notes example mentioned in the introduction. To further complicate matters, tooling to help identify and manage tech debt for software architecture has been missing in comparison to the other aspects of software development: For code quality, observability, and SCA, proven tooling exists with products like Sonarqube, Datadog, New Relic, GitHub, and Snyk. However, the software architecture segment has lagged behind without any proven solutions. This is unfortunate, given the fact that ATD is consistently the largest – and most damaging – type of technical debt, as found in the “ Measure It? Manage It? Ignore It? Software Practitioners and Technical Debt ” 2015 study published by Carnegie Mellon. Measure It? Manage It? Ignore It? Software Practitioners and Technical Debt The following illustration summarizes Figure 4 from that report, concluding that bad architecture choices were the clear leader in sources of technical debt. If not managed, ATD can continue to grow over time at an increasing rate, as demonstrated in this simple illustration: Without mitigation, architecture debt will eventually reach a breaking point for the underlying solution being measured. Managing ATD Before we can manage ATD, we must first understand the problem. Desmond Tutu once wisely said, “There is only one way to eat an elephant: a bite at a time.” Desmond Tutu The shift-left approach embraces the concept of moving a given aspect closer to the beginning than at the end of a lifecycle. This concept gained popularity with shift-left for testing, where the test phase was moved to a part of the development process and not a separate event to be completed after development was finished. Shift-left can be implemented in two different ways in managing ATD: Shift-left for resiliency — identifying sources that have an impact on resiliency and then fixing them before they manifest in performance. Shift-left for security — detect and mitigate security issues during the development lifecycle. Shift-left for resiliency — identifying sources that have an impact on resiliency and then fixing them before they manifest in performance. Shift-left for security — detect and mitigate security issues during the development lifecycle. Just like shift-left for testing, a prioritized focus on resilience and security during the development phase will reduce the potential for unexpected incidents. Architectural observability Architectural observability gives engineering teams the ability to incrementally address architectural drift within their services at a macro level. In fact, the Wall Street Journal reported the cost to fix technical debt at $1.52 trillion earlier this year in “The Invisible $1.52 Trillion Problem: Clunky Old Software,” article . article To be successful, engineering leadership must be in full alignment with the following organizational objectives: Resiliency — to recover swiftly from unexpected incidents. Scalability — to scale appropriately with customer demand. Velocity — to deliver features and enhancements inline with product expectations. Cloud Suitability — transforming legacy solutions into efficient cloud-native service offerings. Resiliency — to recover swiftly from unexpected incidents. Scalability — to scale appropriately with customer demand. Velocity — to deliver features and enhancements inline with product expectations. Cloud Suitability — transforming legacy solutions into efficient cloud-native service offerings. I recently discovered vFunction ’s AI-driven architectural observability platform, which is focused on the following deliverables: vFunction Discover the real architecture of solutions via static and dynamic analysis. Prevent architecture drift via real-time views of how services are evolving. Increase resiliency of applications via the elimination of unnecessary dependencies and improvements between application domains and their associated resources. Manage and remediate tech debt via AI-driven observability. Discover the real architecture of solutions via static and dynamic analysis. Discover Prevent architecture drift via real-time views of how services are evolving. Prevent Increase resiliency of applications via the elimination of unnecessary dependencies and improvements between application domains and their associated resources. resiliency Manage and remediate tech debt via AI-driven observability. remediate Additionally, the vFunction platform provides the side-benefit of providing a migration path to transform from monoliths to cloud-native solutions. Once teams have modernized their platforms, they can continuously observe them for ongoing drift. If companies already have microservices, they can use vFunction to detect complexity in distributed applications and address dependencies that impact resiliency and scalability. In either case, once implemented, engineering teams can mitigate ATD well before reaching the breaking point. In the illustration above, engineering teams are able to mitigate technical debt as a part of each release,due to the implementation of the vFunction platform and an underlying shift-left approach. Conclusion My readers may recall that I have been focused on the following mission statement, which I feel can apply to any IT professional: “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester “Focus your time on delivering features/functionality that extends the value of your intellectual property. Leverage frameworks, products, and services for everything else.” - J. Vester The vFunction platform adheres to my mission statement by helping engineering teams employ a shift-left approach to the resiliency and security of their services at a macro level. This is an important distinction because without such tooling, teams are likely to mitigate at a micro level, resolving tech debt that doesn’t really matter from an organizational perspective. When I think back to that application that made me realize the challenges with tech debt, I can’t help but think about how that solution yielded more issues than it did benefits with each feature that was introduced. Certainly, the use of shift-left for resiliency alone would have helped surface issues with the underlying architecture at a point where the cost of considering alternatives would be feasible. If you are interested in learning more about the vFunction solution, you can read more about them here . here Have a really great day!

Managing Architectural Tech Debt

স্থাপত্য প্রযুক্তি ঋণ ব্যবস্থাপনা

Verwalten von technischen Architekturschulden

Gestión de la deuda tecnológica arquitectónica

Gérer la dette technologique architecturale

वास्तुकला तकनीक ऋण का प्रबंधन

アーキテクチャ技術負債の管理

건축 기술 부채 관리

Gerenciando dívidas de tecnologia arquitetônica

Управление долгом за архитектурные технологии

Mimari Teknoloji Borcunu Yönetmek

Quản lý nợ công nghệ kiến trúc

管理建筑技术债务

Exit Strategies For Tech Entrepreneurs: Knowing When And How To Sell

Recently while trying to integrate a devsecops tool in my pipeline, i was trying to find the GitHub action which would simplify my workflow. Since i could not find it, i have to write the commands inline to run the command. Although it is not a hassle to write it within the script, it would be beneficial to have an action which we could directly call, pass parameters and run the action within the pipeline. In this blog, i will walk you through different steps on how you can create a custom GitHub actions which would satisfy your requirement. The blog will be of 2 parts: Understanding what the GitHub action are Creating your custom GitHub actions GitHub actions: Often when we write pipelines, we would have a set of actions which we would like to perform based on the type of application that we are developing. In order for us to run these actions across the repos in our organization, we would have to copy + paste this code across the repositories, which would make this process error prone and maintenance tussle. It would be better if we take DRY principle of software engineering and apply it to CI/CD world. GitHub action is exactly this principle in practice. We create and host the required action in a certain GitHub public repository and this action is used across the pipeline to perform the action defined in the action. Now that we understand what GitHub action is, lets explore how we can build a custom GitHub action which can help automate set of actions. For this blog, i illustrate it with an example of SBOM enrichment tool Parlay, for which i have built a custom action. Creating Custom Action - A case on Parlay We will be creating our custom action in the following steps: Defining inputs and outputs in action.yml Developing business logic in bash script Dockerize the bash application Test the action Publish it in GitHub action Marketplace Defining inputs and outputs in action.yml To start creating custom action create a custom git repository, clone that repo in your local system and open it up in your favourite code editor. We start by creation a file named actions.yml. This actions.yml defines the inputs that the action would take, the outputs that it would give and the environment it will run. For our use case we have 3 inputs and 1 output. The actions.yml should have following arguments: name: This would be the name of the action, which would be used to search in GitHub action marketplace. Since it would be published in marketplace, it’s name should be globally unique like s3 bucket. description: This describes what your action would do. This would be helpful to identify which action would be the right fit for our use case. inputs: Defines the list of options which would be used within the action. These can be compulsory or optional, which can be defined using “required” argument. In our current use case we are passing 3 arguments, input_file_name, enricher and output_file_name. outputs: This enlists the list of outputs that the action gives. runs: defines the environment in which action will execute , which in our case is docker The action.yml will look something like this: action.yaml

name: "Parlay Github Action"
description: "Runs Parlay on the given input file using the given enricher and outputs it in your given output file"
branding:
icon: "shield"
color: "gray-dark"
inputs:
input_file_name:
description: "Name of the input SBOM file to enrich"
required: true
enricher:
description: "The enricher used to enrich the parlay sbom. Currently parlay supports ecosystems, snyk, scorecard(openssf scorecard)"
required: true
default: ecosystems
output_file_name:
description: "Name of the output file to save the SBOM enriched using the parlay's enricher"
required: true
outputs:
output_file_name:
description: "Prints the output file"
runs:
using: "docker"
image: "Dockerfile"
args:
- ${{ inputs.input_file_name }}
- ${{ inputs.enricher }}
- ${{ inputs.output_file_name }} Developing business logic in bash script Once we have defined the inputs, outputs and environment that we are going to use, we would like to define what we are going to do with those inputs ( basically our logic) in a file. We can either define this in JavaScript or bash. For my current use case, i am using bash. In my current logic, i am going to check if all the inputs are first given, if not the action fails. Once i have these 3 arguments, i am going to construct the command to run the action and save the output in an output file. This file is printed in stdout and formatted using jq utility. #!/bin/bash

Check if all three arguments are provided

if [ "$#" -ne 3 ]; then
echo "Usage: $0 <input> <input_file_name> <output_file_name>"
exit 1
fi

Extract arguments

INPUT_INPUT_FILE_NAME=$1
INPUT_ENRICHER=$2
INPUT_OUTPUT_FILE_NAME=$3

Construct command

full_command="parlay $INPUT_ENRICHER enrich $INPUT_INPUT_FILE_NAME > $INPUT_OUTPUT_FILE_NAME"
eval "$full_command"

Check if the command was successful

if [ $? -eq 0 ]; then
echo "Command executed successfully: $full_command"
cat $INPUT_OUTPUT_FILE_NAME | jq .
else
echo "Error executing command: $full_command"
fi Dockerize the bash application Once we have the bash script ready, we will be dockerizing it using the following script. Whenever we invoke the action, this action which is defined in the bash script runs in an isolated docker container. In addition to the bash script in entrypoint.sh, we would also be adding the the required libraries such as wget, jq and installing parlay binary. Base image

FROM --platform=linux/amd64 alpine:latest

installes required packages for our script

RUN apk add --no-cache bash wget jq

Install parlay

RUN wget https://github.com/snyk/parlay/releases/download/v0.1.4/parlay_Linux_x86_64.tar.gz
RUN tar -xvf parlay_Linux_x86_64.tar.gz

RUN mv parlay /usr/bin/parlay

RUN ls /usr/bin | grep parlay
RUN parlay

Copies your code file  repository to the filesystem

COPY . .

change permission to execute the script and

RUN chmod +x /entrypoint.sh

file to execute when the docker container starts up

ENTRYPOINT ["/entrypoint.sh"] Test the action No amount of software is good without running some tests on it. To test the action, lets first push the code to GitHub. Once pushed, lets define the pipeline in pipeline.yaml file in .github/workflows folder. For the sake of input file, i am using a sample sbom in cyclonedx format and have pushed it to GitHub. In my pipeline.yaml file, i am cloning the GitHub repo and using my action called krishnaduttPanchagnula/parlayaction@main on cyclonedx.json. file on: [push]

jobs:
custom_test:
runs-on: ubuntu-latest
name: We test it locally with act
steps:
- name: Checkout git branch
uses: actions/checkout@v1

  - name: Run Parlay locally and get result
    uses: krishnaduttPanchagnula/parlayaction@main
    id: parlay
    with:
      input_file_name: ./cyclonedx.json
      enricher: ecosystems
      output_file_name: enriched_cyclonedx.json Once the pipeline runs, this should give output in the std-out in pipeline console as follows. Publish it in GitHub action Marketplace Once we have tested the action and that is running fine, we are going to publish it GitHub actions market place. TO do so, our custom app should have globally unique name. To make it more unique we can add icon with our custom to uniquely identify the action in marketplace. symbol and colour Once that is done you would see the button, “Draft a Release”. Ensure that your action.yml file has Name, description, Icon and color. Once you have tick marks, you would be guided to release page where you can mention the title and version of the release. After that, click on “publish release” and you should be able to see your action in GitHub Actions marketplace. Like my content? Feel free to reach out to my for interesting content and productive discussions. LinkedIn

Building & Publishing Your Own Custom GitHub Action in Marketplace

The article will consist of three parts: In the first part, I will discuss the criteria for selecting a library, form a list of libraries, compare them based on the criteria, and choose the three most suitable libraries for further analysis. In the second part, I will compare the functional capabilities of the libraries, identify commonalities and differences, and select two of them for testing. In the third part, I will test the chosen libraries and draw a conclusion about which one I would use for a productive environment. Firstly, it is necessary to determine the criteria for a library suitable for production. Based on my own experience, I will highlight the following criteria: — this is more about ensuring that many developers are familiar with the library, and there is a sufficient community to address emerging difficulties and problems. Popularity and Rating — it is a red flag for me if the library has not been updated for years. This usually means that the library is not evolving and may not support the latest changes in Next.js. Even if everything currently works correctly, there is no guarantee that it won’t break with the next Next.js update. Relevance — this is an important criterion as it allows for faster implementation of the library and significantly simplifies maintenance in the future. Presence of Quality Documentation and Examples — the current version of the library should not have known security issues. Security — the assessment of code cleanliness and readability will always be subjective. In most cases, this is not required, but it can be useful, especially when choosing a less popular and unsupported library at the moment. In this article, we will not consider such libraries, so we will not assess them based on this criterion. Readable Source Code of the Library — it consists of two parts: the library’s size and loading time, and the actual code execution speed in the library. We will try to evaluate this during the testing phase. Performance — the library should meet the functional requirements of the system to avoid searching for workarounds or having to change the library in the middle of development. Functional Capabilities — I will strive to choose libraries for a productive environment that adhere to accepted standards. If necessary, I want to be able to replace one library with another with minimal effort. Adherence to Standards In the first part of the article, we will select libraries and evaluate them based on the first four criteria. Using these criteria, we will choose three libraries for further analysis. In the second part, we will assess the chosen libraries based on criteria 7 and 8. To begin, let’s compile a list of available libraries and look on their popularity: , weekly downloads 2.677.938, last updated 11 days ago react-i18next , weekly downloads 1.311.586, last updated 13 days ago react-intl , weekly downloads 350.234, last updated a month ago next-i18next , weekly downloads 118.061, last updated 3 days ago next-intl , weekly downloads 97.660, last updated 2 months ago @lingui/react m weekly downloads 73.427, last updated 23 days ago next-translate , weekly downloads 21.258, last updated 3 years ago rosetta , weekly downloads 14.404, last updated 2 years ago next-localization This numbers are current as of November 27, 2023. Web development evolves rapidly, and within a few months, the landscape may have changed. Disclaimer: Next, we will not consider and as they have not been updated for more than two years, and as a result, they have the lowest number of downloads, which is constantly decreasing. rosetta next-localization We will check the packages for known vulnerabilities using the Snyk CLI: ~$ snyk test next-intl@latest

Testing next-intl@latest...

Organization:      ***
Package manager:   npm
Open source:       yes
Project path:      next-intl@latest

✔ Tested next-intl@latest for known vulnerabilities, no vulnerable paths found. After checking all packages, we find that all specified packages do not have any known vulnerabilities — excellent! Now, let’s take a look at the documentation. — well-structured and detailed documentation with examples using App Router and Pages Router next-intl — well-structured and detailed documentation, but examples are only described for React applications, requiring adaptation for Next.js @lingui/react — detailed documentation, but in my opinion, poorly structured and overloaded with irrelevant information. Integration example for Next.js leads to a page outside the library documentation react-i18next — detailed documentation on the library and its API, lacking examples of using the library in an application. The documentation is oriented towards React, and adapting the library for use in a Next.js application is required react-intl — detailed single-page documentation with a table of contents, improving navigation. Documentation refers to Next.js version 10, which seems outdated. All examples use Pages Router next-translate — single-page documentation, usage described only with Pages Router, recommends using react-i18next directly for Next.js 13/14 next-i18next Since we will be focusing on developing an application with Next.js 14, we will not consider further, as they recommend using instead. We will also not consider the library as, in my opinion, its documentation does not appear to be up-to-date and convenient enough for easy and quick integration into our future system. next-i18next react-i18next next-translate My personal choice unequivocally falls on as the most qualitatively documented and as the most popular library. next-intl react-i18next Choosing a third option for further analysis seems more challenging, with two libraries competing: and . Both will require additional exploration to integrate into a Next.js 14 application. One is very popular, with over a million downloads per week, while the other has a more structured documentation. @lingui/react react-intl Both of these libraries use approaches that are different from and . uses an additional CLI for extracting translatable strings from page code, which, in my opinion, complicates the development process and makes it harder to abstract translations from the code. uses special javascript objects describing translatable messages. next-intl react-i18next @lingui/react react-intl For further exploration, let’s consider all four libraries: , , , and . We will try to compare their different approaches and the functional capabilities they provide. next-intl react-i18next @lingui/react react-intl If you use other libraries and are confident that they can compete with the ones selected, please let me know in the comments, and I will be sure to investigate them. Subscribe for notifications not to miss the next parts. While you’re waiting for the next round. about our recently launched , a localization platform for modern web applications — an ideal choice for indie developers and small teams. We need your feedback Gitloc We invite you to test our system, which will only take 10–15 minutes, check out . documentation It is crucial for us to receive feedback from developers at this stage. You can leave your feedback in the comments to the latest release in our or write to . Telegram channel feedback@gitloc.org We will definitely support all our early users. , and let’s make localization no longer a headache for developers. Register through the link for free Also published . here

Stories, News & Mentions about SNYK

Snyk’s Stories on HackerNoon

Snyk's News & Mentions