Snyk, valued at over $7 billion and looking to go public, will double the size of its local engineering team.

Why a Boston cybersecurity unicorn is hiring in Boston while rivals move jobs offshore - The Boston Globe

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

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

Over the past three years, I have been exploring and have started to  implement Application Security (AppSec) practices in my work. AppSec  integrates security into the development process, helping developers  identify, understand, fix, and prevent vulnerabilities in their code. It  ensures security is a planned part of the application, rather than a  poorly implemented afterthought for compliance’s sake. Personally, I have found this to be the most approachable way to  actively work in the IT security area that I am passionate about while  improving the quality of my software development work. Understanding The Attack Surface The first step is understanding your attack surface and vectors.  Understanding by attack surface the sum of all possible entry points an  attacker could use, and by attack vectors  the specific methods they  might employ. You can’t protect what you don’t know is there, and it is easier to protect against threats you are aware of. The easiest way to familiarize yourself with potential threats is by checking the OWASP Top 10,  or with the Top 10 specific to your area. These lists cover the most  critical and common security risks that an application can face. Just by  going over the list, you can get an idea of what areas need to be  checked or improved, and how to test them better. Going even further and approaching this in a more structured way, we  can look into threat modeling. This offers a systematic approach to  identifying, assessing the impact, and mitigating potential security  threats. Frameworks like STRIDE, DREAD, and PASTA can guide us in better  securing our applications, anticipating attack scenarios, and building  more resilient systems. But lets remember that not everything is worth defending, especially  when the damage or the likelihood is minimal. Think of this as how home  insurance covers fire but not meteors, they can happen but how likely is  that? Leveraging Automation Automation can simplify our lives and play a crucial role in  maintaining consistency. The two main areas where we can start  automating our security practices are Static Application Security  Testing (SAST) and Dynamic Application Security Testing (DAST). SAST analyzes the source code itself, identifying errors and vulnerabilities before the application is even running. Tools like SonarQube  can be integrated into our IDE or CI/CD pipeline to enforce secure  coding practices and track code quality. Also, Software Composition  Analysis (SCA) tools such as Dependabot, Snyk, and OWASP  Dependency-Check help detect known vulnerabilities in your dependencies,  which become our vulnerabilities if we are using them. The Log4J  incident at the end of 2021 is a good example of this. DAST focuses on what happens when the app is running. Tools like  OWASP ZAP, Burp Suite and Acunetix can simulate real-world attacks,  throwing structured and random inputs at our application to see how it  responds and to identify possible vulnerabilities, misconfigurations or  errors in logic. Defense in Depth There is no magic tool or solution that can solve all your security  problems. Instead, we need to layer multiple solutions, each tailored  and focused on its own domain. This layering makes it much more  difficult for a vulnerability or an attack to be successful because if  it is missed in one place, it will likely be caught in another. In this sense, code is also a layer. You can have all the firewalls  and antivirus you want, but if you leave a test account open, there is  nothing those can do about it. Final Thoughts & Actionable Advice Integrating security into the development process doesn’t need to  cost millions or require a whole specialized team. It is about knowing  the basics of your own code and how to mitigate most of the usual  problems. Integrating tools to automate checks is also recommended  because it helps avoid overlooking important aspects and having  repetitive tasks in autopilot. If you are going to do only one thing, I suggest familiarizing  yourself with the OWASP Top 10, understand what each entry means, how  and why it works. This alone puts you ahead of a significant portion of  software developers when it comes to security awareness. Over the past three years, I have been exploring and have started to  implement Application Security (AppSec) practices in my work. AppSec  integrates security into the development process, helping developers  identify, understand, fix, and prevent vulnerabilities in their code. It  ensures security is a planned part of the application, rather than a  poorly implemented afterthought for compliance’s sake. Personally, I have found this to be the most approachable way to  actively work in the IT security area that I am passionate about while  improving the quality of my software development work. Understanding The Attack Surface The first step is understanding your attack surface and vectors.  Understanding by attack surface the sum of all possible entry points an  attacker could use, and by attack vectors  the specific methods they  might employ. You can’t protect what you don’t know is there, and it is easier to protect against threats you are aware of. The easiest way to familiarize yourself with potential threats is by checking the OWASP Top 10 ,  or with the Top 10 specific to your area. These lists cover the most  critical and common security risks that an application can face. Just by  going over the list, you can get an idea of what areas need to be  checked or improved, and how to test them better. OWASP Top 10 Going even further and approaching this in a more structured way, we  can look into threat modeling. This offers a systematic approach to  identifying, assessing the impact, and mitigating potential security  threats. Frameworks like STRIDE, DREAD, and PASTA can guide us in better  securing our applications, anticipating attack scenarios, and building  more resilient systems. But lets remember that not everything is worth defending, especially  when the damage or the likelihood is minimal. Think of this as how home  insurance covers fire but not meteors, they can happen but how likely is  that? Leveraging Automation Automation can simplify our lives and play a crucial role in  maintaining consistency. The two main areas where we can start  automating our security practices are Static Application Security  Testing (SAST) and Dynamic Application Security Testing (DAST). SAST analyzes the source code itself, identifying errors and vulnerabilities before the application is even running. Tools like SonarQube can be integrated into our IDE or CI/CD pipeline to enforce secure  coding practices and track code quality. Also, Software Composition  Analysis (SCA) tools such as Dependabot, Snyk, and OWASP  Dependency-Check help detect known vulnerabilities in your dependencies,  which become our vulnerabilities if we are using them. The Log4J  incident at the end of 2021 is a good example of this. SonarQube DAST focuses on what happens when the app is running. Tools like  OWASP ZAP, Burp Suite and Acunetix can simulate real-world attacks,  throwing structured and random inputs at our application to see how it  responds and to identify possible vulnerabilities, misconfigurations or  errors in logic. Defense in Depth There is no magic tool or solution that can solve all your security  problems. Instead, we need to layer multiple solutions, each tailored  and focused on its own domain. This layering makes it much more  difficult for a vulnerability or an attack to be successful because if  it is missed in one place, it will likely be caught in another. In this sense, code is also a layer. You can have all the firewalls  and antivirus you want, but if you leave a test account open, there is  nothing those can do about it. Final Thoughts & Actionable Advice Integrating security into the development process doesn’t need to  cost millions or require a whole specialized team. It is about knowing  the basics of your own code and how to mitigate most of the usual  problems. Integrating tools to automate checks is also recommended  because it helps avoid overlooking important aspects and having  repetitive tasks in autopilot. If you are going to do only one thing, I suggest familiarizing  yourself with the OWASP Top 10, understand what each entry means, how  and why it works. This alone puts you ahead of a significant portion of  software developers when it comes to security awareness.

Your Code Is a Hacker’s Playground—Here’s How to Lock It Down

Security Things That Matter Security is dull & boring until you get hacked. Then it's REALLY interesting. Node is great at making it easy to create APIs overnight, but that also makes it easy to do it wrong. I have seen others get compromised because of: They employed packages they never audited (npm is wonderful & frightening)
They rely on input from users (never, EVER do that)
They hard-code credentials directly into the code (why in the world?) I am sure you have wondered what you'd do if someone hacked your app. Let’s look at some suggestions to avoid getting hacked. The Basics Check What Users/Customers Send You
Always expect users to attempt strange things. Check ALL OF IT.
// Bad code 
app.post('/users', (req, res) => {
  db.users.create(req.body); // Accepting whatever users send? Bad idea!
});

// Better approach
app.post('/users', (req, res) => {
  // Use something like Joi or express-validator
  if (!req.body.email || !req.body.email.includes('@')) {
    return res.status(400).send('Invalid email');
  }
  if (typeof req.body.age !== 'number') {
    return res.status(400).send('Age must be a number');
  }
  // Now it's safer to save
  db.users.create(req.body);
}); I found this out for myself when someone crashed my application by placing an emoji within the username field. Fun times. Login Stuff: Don't Mess This Up
JWT tokens are cool but simple to get wrong. Here's my take:
// Creating tokens - keep them short lived!
const token = jwt.sign(
  { userId: user.id },
  process.env.JWT_SECRET,
  { expiresIn: '1h' }  // Dont make these last forever
);

// Check tokens on protected routes
function checkAuth(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  
  if (!token) {
    return res.status(401).send('Login required');
  }
  
  try {
    const user = jwt.verify(token, process.env.JWT_SECRET);
    req.user = user;  // Add user info to request
    next();
  } catch (err) {
    return res.status(403).send('Invalid or expired token');
  }
}

// Use it to protect routes
app.get('/profile', checkAuth, (req, res) => {
  // Only logged in users get here
}); Auth has two halves: ensuring that the user is who they say they are (authentication) and ensuring that they can do what they're trying to do (authorization). Never, under any circumstances, commit your database password to GitHub
// NO NO NO - don't hardcode passwords!!
const db = mysql.connect({
  host: 'mydatabase.server.com',
  user: 'admin',
  password: 'SuperSecret123!'  // This should never be in your code
});

// Do this instead
require('dotenv').config();

const db = mysql.connect({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD
}); And DO NOT forget to place your .env file to .gitignore. Real Security Problems I've Seen SQL Injection Still Works?! Yes, it does. And it is so easy to stop:
// Dangerous - allows SQL injection
app.get('/users', (req, res) => {
  const name = req.query.name;
  db.query(`SELECT * FROM users WHERE name = '${name}'`,  // BAD!
    (err, results) => res.json(results)
  );
});

// Safe - use parameters
app.get('/users', (req, res) => {
  const name = req.query.name;
  db.query('SELECT * FROM users WHERE name = ?', 
    [name],  // This prevents SQL injection
    (err, results) => res.json(results)
    );
  }); When someone attempts ?name=x'; DROP TABLE users; -- you will be happy you utilized parameters. Too Many Requests = Crashed Server
The app crashed when a user abused the search API too much. Implement rate limiting: const rateLimit = require('express-rate-limit');

// Basic protection for all routes
const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,  // 15 minutes
  max: 100  // limit per IP
});

app.use(limiter);

// Extra protection for login attempts
const loginLimiter = rateLimit({
  windowMs: 60 * 60 * 1000,  // 1 hour
  max: 5  // 5 login attempts per hour
});

app.use('/login', loginLimiter); Old Packages = Security Holes
Most hacks happen through outdated packages. Check yours:
# Run this often!
npm audit

# Fix what you can
npm audit fix Use Helmet for HTTP Headers One line of code that fixes several issues: const helmet = require('helmet');
app.use(helmet());  // Adds security headers FAQs that every Developer should know Q: What do you need to fix first that is most important? A: Input validation. Most attacks start there. Q: What is the best way to know if my API security is sufficient? A: Have someone attempt to break it. Or you can try a tool like OWASP ZAP. Q: How can I prevent security vulnerabilities caused by dependencies?A: Schedule a calendar event to update your dependencies in a timely manner. To detect these vulnerabilities, consider using tools like npm audit, snyk, or dependable. Q: What is the best way to know if my API security is sufficient? A: Have someone attempt to break it. Or you can try a tool like OWASP ZAP. Final Thoughts - Lessons to learn from Security is not an afterthought - it should be built into the code from the outset. Start with these basics: Authenticate all users
Secure your auth routes
Store Secrets in Environment Variables
Update dependencies
Set rate limits
Always use HTTPS So, which gap will you be closing today? Security Things That Matter Security Things That Matter Security is dull & boring until you get hacked. Then it's REALLY interesting. Node is great at making it easy to create APIs overnight, but that also makes it easy to do it wrong. I have seen others get compromised because of: They employed packages they never audited (npm is wonderful & frightening) They rely on input from users (never, EVER do that) They hard-code credentials directly into the code (why in the world?) They employed packages they never audited (npm is wonderful & frightening) They rely on input from users (never, EVER do that) They hard-code credentials directly into the code (why in the world?) I am sure you have wondered what you'd do if someone hacked your app. Let’s look at some suggestions to avoid getting hacked. The Basics The Basics Check What Users/Customers Send You
Always expect users to attempt strange things. Check ALL OF IT.
// Bad code 
app.post('/users', (req, res) => {
  db.users.create(req.body); // Accepting whatever users send? Bad idea!
});

// Better approach
app.post('/users', (req, res) => {
  // Use something like Joi or express-validator
  if (!req.body.email || !req.body.email.includes('@')) {
    return res.status(400).send('Invalid email');
  }
  if (typeof req.body.age !== 'number') {
    return res.status(400).send('Age must be a number');
  }
  // Now it's safer to save
  db.users.create(req.body);
}); Check What Users/Customers Send You Always expect users to attempt strange things. Check ALL OF IT. // Bad code 
app.post('/users', (req, res) => {
  db.users.create(req.body); // Accepting whatever users send? Bad idea!
});

// Better approach
app.post('/users', (req, res) => {
  // Use something like Joi or express-validator
  if (!req.body.email || !req.body.email.includes('@')) {
    return res.status(400).send('Invalid email');
  }
  if (typeof req.body.age !== 'number') {
    return res.status(400).send('Age must be a number');
  }
  // Now it's safer to save
  db.users.create(req.body);
}); Check What Users/Customers Send You Check What Users/Customers Send You Always expect users to attempt strange things. Check ALL OF IT. // Bad code 
app.post('/users', (req, res) => {
  db.users.create(req.body); // Accepting whatever users send? Bad idea!
});

// Better approach
app.post('/users', (req, res) => {
  // Use something like Joi or express-validator
  if (!req.body.email || !req.body.email.includes('@')) {
    return res.status(400).send('Invalid email');
  }
  if (typeof req.body.age !== 'number') {
    return res.status(400).send('Age must be a number');
  }
  // Now it's safer to save
  db.users.create(req.body);
}); // Bad code 
app.post('/users', (req, res) => {
  db.users.create(req.body); // Accepting whatever users send? Bad idea!
});

// Better approach
app.post('/users', (req, res) => {
  // Use something like Joi or express-validator
  if (!req.body.email || !req.body.email.includes('@')) {
    return res.status(400).send('Invalid email');
  }
  if (typeof req.body.age !== 'number') {
    return res.status(400).send('Age must be a number');
  }
  // Now it's safer to save
  db.users.create(req.body);
}); I found this out for myself when someone crashed my application by placing an emoji within the username field. Fun times. Login Stuff: Don't Mess This Up
JWT tokens are cool but simple to get wrong. Here's my take:
// Creating tokens - keep them short lived!
const token = jwt.sign(
  { userId: user.id },
  process.env.JWT_SECRET,
  { expiresIn: '1h' }  // Dont make these last forever
);

// Check tokens on protected routes
function checkAuth(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  
  if (!token) {
    return res.status(401).send('Login required');
  }
  
  try {
    const user = jwt.verify(token, process.env.JWT_SECRET);
    req.user = user;  // Add user info to request
    next();
  } catch (err) {
    return res.status(403).send('Invalid or expired token');
  }
}

// Use it to protect routes
app.get('/profile', checkAuth, (req, res) => {
  // Only logged in users get here
}); Login Stuff: Don't Mess This Up JWT tokens are cool but simple to get wrong. Here's my take: // Creating tokens - keep them short lived!
const token = jwt.sign(
  { userId: user.id },
  process.env.JWT_SECRET,
  { expiresIn: '1h' }  // Dont make these last forever
);

// Check tokens on protected routes
function checkAuth(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  
  if (!token) {
    return res.status(401).send('Login required');
  }
  
  try {
    const user = jwt.verify(token, process.env.JWT_SECRET);
    req.user = user;  // Add user info to request
    next();
  } catch (err) {
    return res.status(403).send('Invalid or expired token');
  }
}

// Use it to protect routes
app.get('/profile', checkAuth, (req, res) => {
  // Only logged in users get here
}); Login Stuff: Don't Mess This Up Login Stuff: Don't Mess This Up JWT tokens are cool but simple to get wrong. Here's my take: // Creating tokens - keep them short lived!
const token = jwt.sign(
  { userId: user.id },
  process.env.JWT_SECRET,
  { expiresIn: '1h' }  // Dont make these last forever
);

// Check tokens on protected routes
function checkAuth(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  
  if (!token) {
    return res.status(401).send('Login required');
  }
  
  try {
    const user = jwt.verify(token, process.env.JWT_SECRET);
    req.user = user;  // Add user info to request
    next();
  } catch (err) {
    return res.status(403).send('Invalid or expired token');
  }
}

// Use it to protect routes
app.get('/profile', checkAuth, (req, res) => {
  // Only logged in users get here
}); // Creating tokens - keep them short lived!
const token = jwt.sign(
  { userId: user.id },
  process.env.JWT_SECRET,
  { expiresIn: '1h' }  // Dont make these last forever
);

// Check tokens on protected routes
function checkAuth(req, res, next) {
  const token = req.headers.authorization?.split(' ')[1];
  
  if (!token) {
    return res.status(401).send('Login required');
  }
  
  try {
    const user = jwt.verify(token, process.env.JWT_SECRET);
    req.user = user;  // Add user info to request
    next();
  } catch (err) {
    return res.status(403).send('Invalid or expired token');
  }
}

// Use it to protect routes
app.get('/profile', checkAuth, (req, res) => {
  // Only logged in users get here
}); Auth has two halves: ensuring that the user is who they say they are (authentication) and ensuring that they can do what they're trying to do (authorization). Never, under any circumstances, commit your database password to GitHub
// NO NO NO - don't hardcode passwords!!
const db = mysql.connect({
  host: 'mydatabase.server.com',
  user: 'admin',
  password: 'SuperSecret123!'  // This should never be in your code
});

// Do this instead
require('dotenv').config();

const db = mysql.connect({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD
}); Never, under any circumstances, commit your database password to GitHub // NO NO NO - don't hardcode passwords!!
const db = mysql.connect({
  host: 'mydatabase.server.com',
  user: 'admin',
  password: 'SuperSecret123!'  // This should never be in your code
});

// Do this instead
require('dotenv').config();

const db = mysql.connect({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD
}); Never, under any circumstances, commit your database password to GitHub Never, under any circumstances, commit your database password to GitHub // NO NO NO - don't hardcode passwords!!
const db = mysql.connect({
  host: 'mydatabase.server.com',
  user: 'admin',
  password: 'SuperSecret123!'  // This should never be in your code
});

// Do this instead
require('dotenv').config();

const db = mysql.connect({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD
}); // NO NO NO - don't hardcode passwords!!
const db = mysql.connect({
  host: 'mydatabase.server.com',
  user: 'admin',
  password: 'SuperSecret123!'  // This should never be in your code
});

// Do this instead
require('dotenv').config();

const db = mysql.connect({
  host: process.env.DB_HOST,
  user: process.env.DB_USER,
  password: process.env.DB_PASSWORD
}); And DO NOT forget to place your .env file to .gitignore. Real Security Problems I've Seen Real Security Problems I've Seen SQL Injection Still Works?! Yes, it does. And it is so easy to stop:
// Dangerous - allows SQL injection
app.get('/users', (req, res) => {
  const name = req.query.name;
  db.query(`SELECT * FROM users WHERE name = '${name}'`,  // BAD!
    (err, results) => res.json(results)
  );
});

// Safe - use parameters
app.get('/users', (req, res) => {
  const name = req.query.name;
  db.query('SELECT * FROM users WHERE name = ?', 
    [name],  // This prevents SQL injection
    (err, results) => res.json(results)
    );
  }); SQL Injection Still Works?! Yes, it does. And it is so easy to stop: // Dangerous - allows SQL injection
app.get('/users', (req, res) => {
  const name = req.query.name;
  db.query(`SELECT * FROM users WHERE name = '${name}'`,  // BAD!
    (err, results) => res.json(results)
  );
});

// Safe - use parameters
app.get('/users', (req, res) => {
  const name = req.query.name;
  db.query('SELECT * FROM users WHERE name = ?', 
    [name],  // This prevents SQL injection
    (err, results) => res.json(results)
    );
  }); SQL Injection Still Works?! Yes, it does. And it is so easy to stop: // Dangerous - allows SQL injection
app.get('/users', (req, res) => {
  const name = req.query.name;
  db.query(`SELECT * FROM users WHERE name = '${name}'`,  // BAD!
    (err, results) => res.json(results)
  );
});

// Safe - use parameters
app.get('/users', (req, res) => {
  const name = req.query.name;
  db.query('SELECT * FROM users WHERE name = ?', 
    [name],  // This prevents SQL injection
    (err, results) => res.json(results)
    );
  }); // Dangerous - allows SQL injection
app.get('/users', (req, res) => {
  const name = req.query.name;
  db.query(`SELECT * FROM users WHERE name = '${name}'`,  // BAD!
    (err, results) => res.json(results)
  );
});

// Safe - use parameters
app.get('/users', (req, res) => {
  const name = req.query.name;
  db.query('SELECT * FROM users WHERE name = ?', 
    [name],  // This prevents SQL injection
    (err, results) => res.json(results)
    );
  }); When someone attempts ?name=x'; DROP TABLE users; -- you will be happy you utilized parameters. Too Many Requests = Crashed Server
The app crashed when a user abused the search API too much. Implement rate limiting: Too Many Requests = Crashed Server The app crashed when a user abused the search API too much. Implement rate limiting: Too Many Requests = Crashed Server Too Many Requests = Crashed Server The app crashed when a user abused the search API too much. Implement rate limiting: const rateLimit = require('express-rate-limit');

// Basic protection for all routes
const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,  // 15 minutes
  max: 100  // limit per IP
});

app.use(limiter);

// Extra protection for login attempts
const loginLimiter = rateLimit({
  windowMs: 60 * 60 * 1000,  // 1 hour
  max: 5  // 5 login attempts per hour
});

app.use('/login', loginLimiter); const rateLimit = require('express-rate-limit');

// Basic protection for all routes
const limiter = rateLimit({
  windowMs: 15 * 60 * 1000,  // 15 minutes
  max: 100  // limit per IP
});

app.use(limiter);

// Extra protection for login attempts
const loginLimiter = rateLimit({
  windowMs: 60 * 60 * 1000,  // 1 hour
  max: 5  // 5 login attempts per hour
});

app.use('/login', loginLimiter); Old Packages = Security Holes
Most hacks happen through outdated packages. Check yours:
# Run this often!
npm audit

# Fix what you can
npm audit fix Old Packages = Security Holes Most hacks happen through outdated packages. Check yours: # Run this often!
npm audit

# Fix what you can
npm audit fix Old Packages = Security Holes Old Packages = Security Holes Most hacks happen through outdated packages. Check yours: # Run this often!
npm audit

# Fix what you can
npm audit fix # Run this often!
npm audit

# Fix what you can
npm audit fix Use Helmet for HTTP Headers Use Helmet for HTTP Headers One line of code that fixes several issues: const helmet = require('helmet');
app.use(helmet());  // Adds security headers const helmet = require('helmet');
app.use(helmet());  // Adds security headers FAQs that every Developer should know FAQs that every Developer should know Q: What do you need to fix first that is most important? A: Input validation. Most attacks start there. Q: What is the best way to know if my API security is sufficient? A: Have someone attempt to break it. Or you can try a tool like OWASP ZAP. Q: How can I prevent security vulnerabilities caused by dependencies? A: Schedule a calendar event to update your dependencies in a timely manner. To detect these vulnerabilities, consider using tools like npm audit, snyk, or dependable. Q: What is the best way to know if my API security is sufficient? A: Have someone attempt to break it. Or you can try a tool like OWASP ZAP. Final Thoughts - Lessons to learn from Final Thoughts - Lessons to learn from Security is not an afterthought - it should be built into the code from the outset. Start with these basics: Authenticate all users Secure your auth routes Store Secrets in Environment Variables Update dependencies Set rate limits Always use HTTPS Authenticate all users Secure your auth routes Store Secrets in Environment Variables Update dependencies Set rate limits Always use HTTPS So, which gap will you be closing today?

The Developer’s Guide to Bulletproof API Security in Node.js

Previously Undisclosed Flaw Let Hackers Hijack Millions of Systems Through Innocent-Looking Files

পূর্বে অপ্রকাশিত ত্রুটি হ্যাকারদের নির্দোষ চেহারার ফাইলগুলির মাধ্যমে লক্ষ লক্ষ সিস্টেম হাইজ্যাক করতে দেয়

Una falla no revelada anteriormente permitió a los piratas informáticos secuestrar millones de sistemas mediante archivos de apariencia inocente

Aurretik ezagutarazi gabeko akatsak Hackerrek milioika sistema bahitu ditzakete itxura errugabeko fitxategien bidez

Une faille jusqu'alors non révélée a permis aux pirates de pirater des millions de systèmes via des fichiers apparemment innocents

Una falla precedentemente non rivelata ha permesso agli hacker di dirottare milioni di sistemi tramite file dall'aspetto innocente

これまで公表されていなかった欠陥により、ハッカーは無害に見えるファイルを通じて何百万ものシステムを乗っ取ることが可能

កំហុសដែលមិនបានបង្ហាញពីមុន អនុញ្ញាតឱ្យពួក Hacker លួចចូលប្រព័ន្ធរាប់លានតាមរយៈឯកសារដែលមើលទៅគ្មានកំហុស

Faute oyo elobamaki te liboso Tika ba pirates ba détourner ba millions ya ba systèmes na nzela ya ba fichiers oyo emonanaka lokola innocent

Өмнө нь илчлэгдэж байгаагүй алдаа нь хакеруудад гэмгүй мэт харагдах файлуудаар дамжуулан сая сая системийг хулгайлах боломжийг олгосон.

Ранее нераскрытая уязвимость позволила хакерам взломать миллионы систем с помощью невинных на вид файлов

Mbere Amakosa Ataramenyekana Reka Hackers Banyere Amamiriyoni ya Sisitemu Binyuze muri dosiye zisa n'inzirakarengane

Ilgari oshkor etilmagan kamchilik xakerlarga begunoh ko'rinadigan fayllar orqali millionlab tizimlarni o'g'irlashiga imkon berdi.

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

Stories, News & Mentions about SNYK

Categories

Trending Topics

Stories, News & Mentions about SNYK

Snyk’s Stories on HackerNoon

Snyk's News & Mentions

Categories

Trending Topics