Великденски заек или просто заек за БНБ?

Post Syndicated from Емилия Милчева original https://toest.bg/velikdenski-zaek-ili-prosto-zaek-za-bnb/

Когато премиерът Кирил Петков казва, че подкрепя кандидатурата на Андрей Гюров за управител на БНБ, това не значи нищо. Нима някой е очаквал един от двамата лидери на „Продължаваме промяната“ да не защити номинацията на политическата сила? „Аз го познавам – човек с невероятен етичен кодекс, професионалист. Така че – да, аз лично слагам своето име зад неговата кандидатура“, заяви Кирил Петков. Ако тези суперлативи бяха казани например от някого като Марио Драги, бившия председател на Европейската централна банка, щяха да са стойностна референция.

Неубедително е Петков да гарантира за професионализма на Гюров –

със същия успех може да го направи и Христо Стоичков. Поради тази причина и атестацията, дадена от лидера на „Има такъв народ“ Слави Трифонов за кандидата на ИТН Любомир Каримански и неговите професионални и морални качества, не тежи. „За позицията шеф на Българска народна банка аз и моите сътрудници имаме достойнството животът да ни е срещнал с човек, за когото сме се убедили, че е най-хубавата кандидатура“, казва Трифонов. Виж ти, какъв matchmaker бил този живот!

Изобщо, от дебатите за нов управител на БНБ за следващите 6 години професионализмът отсъства – както сред депутатите анкетьори на номинираните при изслушването им в Бюджетната комисия, така и в повечето медии, където банкерите просто ги няма. Ако не броим бившия шеф на „УниКредит Булбанк“, бивш председател на Асоциацията на търговските банки Левон Хампарцумян и настоящ председател на Българския форум на бизнес лидерите, който впрочем също заяви, че двамата кандидати не са особено убедителни. „Постиженията им не са толкова впечатляващи, но са си „напудрили“ CV-тата. Като ги сравним с екипа, който сега управлява БНБ, не са особено сравними“, каза Хампарцумян по bTV.

Ако двамата кандидати бяха извън политиката, дали от ПП или ИТН щяха да ги издигнат,

запита реторично и проф. Гарабед Минасян, професор в Икономическия институт на БАН, бивш член на Управителния съвет на БНБ. „За Българската банка за развитие вие трябва да сте довереник на тези, които управляват в момента, докато за БНБ, която е част от емисионната система на ЕС, следователно и на еврото, трябва да имате доверие на ЕЦБ, на МВФ, Европейската банка за развитие, Европейската инвестиционна банка като минимум“, обясни и икономистът Красен Станчев по БНР. Според него това, което се случва с избора на шеф на БНБ, е „доста тревожно, да не кажа по-тежка дума“.

Именно номинациите, които са повече политически, отколкото експертни (и зад всяка стоят определени кръгове), създават опасения. Политическото интересчийство доминираше при изборите на най-дълго управлявалия гуверньор на БНБ Иван Искров – от времената на Царя до втория кабинет на Бойко Борисов, в чийто мандат гръмна Корпоративна търговска банка. Искров пя „Назад, назад, моме Калино“ с мажоритарния собственик на КТБ Цветан Василев, прегръщаше се с министъра на финансите на ГЕРБ Владислав Горанов. БНБ през всичките тези години така и не провидя, че държавата крепи КТБ с парите на данъкоплатците, а банката ги прелива в свързани фирми.

Осем години след рухването на КТБ банковата система още изпитва ефектите,

а Фондът за гарантиране на влоговете в банките не е напълно възстановен. Сметката на загубените в КТБ пари е за близо 5 млрд. лв. Нов банков фалит би струвал много повече, включително и като спирачка по пътя към еврото. Може ли Гюров и Каримански да гарантират, че „Банков надзор“ ще работи толкова съвестно, че никоя банка няма да гръмне? Ръководството на БНБ отговаря за стабилността на банковата система и под негов контрол са всички останали банки след първите големи пет, които са под пряк надзор на ЕЦБ след приемането на България в Банковия съюз на ЕС.

Настоящият управител на БНБ Димитър Радев бе издигнат от ГЕРБ през 2015 г., но в пленарната зала бе избран със 130 гласа, тъй като получи подкрепа и от депутати от Реформаторския блок, БДЦ, АБВ и седмина от ДПС. Професионалната му кариера включва 21 години в Министерството на финансите, където стигна до поста на заместник-министър, и последвали 14 години в Международния валутен фонд.

Политическите апетити към поста на управител на БНБ са огромни.

Не отсега, както е добре известно, но се разпалват от възможността за управление (в т.ч. инвестиране) на милиарди – когато България се присъедини към еврозоната. Което дори да не е от 1 януари 2024 г., все пак ще стане в 6-годишния мандат на бъдещия гуверньор. (В едно от редките си интервюта, дадено в началото на март пред „24 часа“, управителят на БНБ Димитър Радев казва, че имаме всички шансове да се присъединим на уречената дата.)

Част от валутните резерви на България ще бъдат прехвърлени към ЕЦБ, но част от тях ще останат тук. Колко – отсега няма как да се каже, но със сигурност десетки милиарди. Към момента валутните резерви на България са близо 60 млрд. лв., а след няколко години стойността им ще е още по-голяма. Тези средства ще се инвестират в съответствие с изисквания на ЕЦБ, но все пак при по-голяма свобода. Без значение какви политически сили ще влизат тогава в правителството, гуверньорът на БНБ ще принадлежи към определен кръг – в случай че парламентът одобри един от двамата кандидати. И разбира се, в случай че той действително подкрепя пътя към еврото, без да се опита да шиканира процеса.

Законът за БНБ дава възможност на управителя да избере подуправители,

а мандатите на двама от настоящите бездруго са изтекли. Каквито и хора да са подбрали за тези постове Гюров или Каримански (готови са с номинациите), те едва ли ще имат по-голям опит от тях самите. Това означава, че който и да поеме управление „Емисионно“ (валутния борд) например, няма да притежава по-голяма експертност от настоящия подуправител Калин Христов, който работи в БНБ от 1997 г. и повече от 15 години е член на Комитета по парична политика на ЕЦБ. С над 16 години опит в БНБ и специализация в ЕЦБ е и другият подуправител, чийто мандат е изтекъл – Нина Стоянова, шеф на управление „Банково“.

Когато България приеме еврото, съвместно с Министерството на финансите БНБ ще води монетарна политика – нещо, което до настоящия момент не е вършила активно заради системата на валутния борд. Но след приемането на еврото ще трябва да работи в по-голям синхрон с правителството и конкретно с министъра на финансите, а главно – с ЕЦБ. Така че опит в БНБ, МФ или международна финансова институция на висока позиция е от съществено значение за гуверньора на централната банка.

Само дето никой от двамата кандидати не го притежава.

Основателят на Института за пазарна икономика Красен Станчев предупреди, че е доста неразумно да се правят смени в БНБ в момента. „При положение че имате хора с опит, които са в момента начело на централна банка, преминали в миналото си през различни кризисни ситуации – както вътрешни, така и външни, то най-добре е сега, когато се очаква голям стрес на европейската банкова система, ЕЦБ и ЕС не само поради войната в Украйна, да не се сменят тези хора“, заяви Станчев.

Има основание за такова предупреждение – заради войната бяха наложени сериозни санкции на Русия, като забрани за транзакции, свързани с руските резерви, спиране на евро към Русия и изключване на 7 руски банки от SWIFT. Тези действия може да предизвикат кибератаки, да носят рискове за платежните системи и други заплахи и неопитни хора начело на БНБ ще се затруднят да управляват подобни кризи.

Нелепи и смехотворни са опитите на представители на управляващата коалиция да обясняват наличието на двама свои кандидати със

силата на демокрацията.

„В нашата коалиция има възможност за демокрация, всеки да си представи кандидата, който счита, че е най-добър, и вече парламентът да реши“, каза премиерът Кирил Петков. В действителност липсата на единна кандидатура, за което например успя да се договори коалицията в Германия за гуверньор на Бундесбанк, е сериозна слабост. Четирите политически сили не поставиха темата за предстоящите смени в регулаторите (КЕВР, КФН и др.), както и в ръководството на БНБ на преговорите за коалиционно споразумение. Всъщност най-сериозните въпроси просто бяха заобиколени и последствията вече са налице само след първите три месеца управление.

В ситуация, в която управляващата коалиция не е единна, никой от двамата кандидати не може да бъде избран, ако не получи помощ от опозицията – ГЕРБ, ДПС или ГЕРБ и ДПС. Дали това ще се случи, или не, ще стане ясно преди Великден. В опит максимално да улеснят избора, от ПП решиха да повтарят срамните практики от предишни парламенти –

игрите с кворума.

Председателят на 47-мото НС Никола Минчев (ПП) обяви, че връща практиката на 44-тото НС относно гласуването на законите и необходимия кворум: „За да бъде едно предложение прието, трябва да са гласували повече от половината от последно регистрираните или съобразно последната проверка на кворума.“ Това означава, че кандидат за управител на БНБ може да бъде одобрен само с 61 гласа – тъй като кворумът е 121. Срамно предложение. Досега всеки гуверньор на БНБ е бил избиран с гласовете на повече от половината народни представители, тоест над 120.

Докато се стигне до гласуването в пленарната зала, тече пазарлъкът между партиите. До момента ПП и ДБ са декларирали публично подкрепа за Андрей Гюров. БСП се пазари кой ще даде повече, за да реши Корнелия Нинова кому да дари 26-те гласа на депутатите социалисти, но по-вероятно е да ги прехвърли към Гюров. Има какво да търгува – нови постове, отказ да приемат предложението на ДБ за изгонването на руската посланичка Митрофанова. Досега Нинова е показала, че добре се справя с тази работа – България ще прати на Украйна само 4000 каски и бронежилетки, не и оръжие, както настояваше „Демократична България“.

И така, новият управител на БНБ едва ли ще е великденски заек. По-скоро зайче, измъкнато с фокус-мокус.

Заглавна снимка: Bjoertvedt / Wikimedia

Източник

[$] Gathering multiple system parameters in a single call

Post Syndicated from original https://lwn.net/Articles/890449/

Running a command like lsof,
which lists the open files on the system along with information about the
process that has each file open, takes a lot of system calls, mostly to read a
small amount of information from many /proc files. Providing a
new interface to collect those calls together into a single (or, at least,
fewer) system calls is the target of Miklos Szeredi’s getvalues()
RFC patch that was posted on March 22. While the proposal does
not look like it is going far, at least in its current form, it did spark
some discussion of the need—or lack thereof—for a way to reduce this kind
of overhead, as well as to explore some alternative ways to get there via code that
already exists in the kernel.

Announcing AWS Lambda Function URLs: Built-in HTTPS Endpoints for Single-Function Microservices

Post Syndicated from Alex Casalboni original https://aws.amazon.com/blogs/aws/announcing-aws-lambda-function-urls-built-in-https-endpoints-for-single-function-microservices/

Organizations are adopting microservices architectures to build resilient and scalable applications using AWS Lambda. These applications are composed of multiple serverless functions that implement the business logic. Each function is mapped to API endpoints, methods, and resources using services such as Amazon API Gateway and Application Load Balancer.

But sometimes all you need is a simple way to configure an HTTPS endpoint in front of your function without having to learn, configure, and operate additional services besides Lambda. For example, you might need to implement a webhook handler or a simple form validator that runs within an individual Lambda function.

Today, I’m happy to announce the general availability of Lambda Function URLs, a new feature that lets you add HTTPS endpoints to any Lambda function and optionally configure Cross-Origin Resource Sharing (CORS) headers.

This lets you focus on what matters while we take care of configuring and monitoring a highly available, scalable, and secure HTTPS service.

How Lambda Function URLs Work
Create a new function URL and map it to any function. Each function URL is globally unique and can be associated with a function’s alias or the function’s unqualified ARN, which implicitly invokes the $LATEST version.

For example, if you map a function URL to your $LATEST version, each code update will be available immediately via the function URL. On the other hand, I’d recommend mapping a function URL to an alias, so you can safely deploy new versions, perform some integration tests, and then update the alias when you’re ready. This also lets you implement weighted traffic shifting and safe deployments.

Function URLs are natively supported by the Lambda API, and you can start using it via the AWS Management Console or AWS SDKs, as well as infrastructure as code(IaC) tools such as AWS CloudFormation, AWS SAM, or AWS Cloud Development Kit (AWS CDK).

Lambda Function URLs in Action
You can configure a function URL for a new or an existing function. Let’s see how to implement a new function to handle a webhook.

When creating a new function, I check Enable function URL in Advanced Settings.

Here, I select Auth type: AWS_IAM or NONE. My webhook will use custom authorization logic based on a signature provided in the HTTP headers. Therefore, I’ll choose AuthType None, which means Lambda won’t check for any AWS IAM Sigv4 signatures before invoking my function. Instead, I’ll extract and validate a custom header in my function handler for authorization.

AWS Lambda URLs - Create Function

Please note that when using AuthType None, my function’s resource-based policy must still explicitly allow for public access. Otherwise, unauthenticated requests will be rejected. You can add permissions programmatically using the AddPermission API. In this case, the Lambda console automatically adds the necessary policy for me, as the IAM role I’m using is authorized to call the AddPermission API in my account.

With one click, I can also enable CORS. The default CORS configuration will allow all origins. Then, I’ll add more granular controls after creating the function. In case you’re not familiar with CORS, it’s a header-based security mechanism implemented by browsers to make sure that only certain hosts are allowed to load resources and invoke APIs. If a website is allowed to consume your API, you’ll need to include a few CORS headers that declare which origins, methods, and custom headers are allowed. The new function URLs take care of it for you, so you don’t have to implement all of this in your Lambda handler.

A few seconds later, the function URL is available. I can also easily find and copy it in the Lambda console.

AWS Lambda URLs - Console URL

The function code that handles my webhook in Node.js looks like this:

exports.handler = async (event) => {
    
    // (optional) fetch method and querystring
    const method = event.requestContext.http.method;
    const queryParam = event.queryStringParameters.myCustomParameter;
    console.log(`Received ${method} request with ${queryParam}`)
    
    // retrieve signature and payload
    const webhookSignature = event.headers.SignatureHeader;
    const webhookPayload = JSON.parse(event.body);
    
    try {
        validateSignature(webhookSignature); // throws if invalid signature
        handleEvent(webhookPayload); // throws if processing error
    } catch (error) {
        console.error(error)
        return {
            statusCode: 400,
            body: `Cannot process event: ${error}`,
        }
    }

    return {
        statusCode: 200, // default value
        body: JSON.stringify({
            received: true,
        }),
    };
};

The code is extracting a few parameters from the request headers, query string, and body. If you’re already familiar with the event structure provided by API Gateway or Application Load Balancer, this should look very familiar.

After updating the code, I decide to test the function URL with an HTTP client.

For example, here’s how I’d do it with curl:

$ curl "https://4iykoi7jk2kp5hhd5irhbdprn40yxest.lambda-url.us-west-2.on.aws/?myCustomParameter=squirrel"
    -X POST
    -H "SignatureHeader: XYZ"
    -H "Content-type: application/json"
    -d '{"type": "payment-succeeded"}'

Or with a Python script:

import json
import requests

url = "https://4iykoi7jk2kp5hhd5irhbdprn40yxest.lambda-url.us-west-2.on.aws/"
headers = {'SignatureHeader': 'XYZ', 'Content-type': 'application/json'}
payload = json.dumps({'type': 'payment-succeeded'})
querystring = {'myCustomParameter': 'squirrel'}

r = requests.post(url=url, params=querystring, data=payload, headers=headers)
print(r.json())

Don’t forget to set the request’s Content-type to application/json or text/* in your tests, otherwise, the body will be base64-encoded by default, and you’ll need to decode it in the Lambda handler.

Of course, in this case we’re talking about a webhook, so this function will receive requests directly from the external system that I’m integrating with. I only need to provide them with the public function URL and start receiving events.

For this specific use case, I don’t need any CORS configuration. In other cases where the function URL is called from the browser, I’d need to configure a few more CORS parameters such as Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Expose-Headers. I can easily review and edit these CORS parameters in the Lambda console or in my IaC templates. Here’s what it looks like in the console:

AWS Lambda URLs - CORS

Also, keep in mind that each function URL is unique and mapped to a specific alias or the $LATEST version of your function. This lets you define multiple URLs for the same function. For example, you can define one for testing the $LATEST version during development and one for each stage or alias, such as staging, production, and so on.

Support for Infrastructure as Code (IaC)
You can start configuring Lambda Function URLs directly in your IaC templates today using AWS CloudFormation, AWS SAM, and AWS Cloud Development Kit (AWS CDK).

For example, here’s how to define a Lambda function and its public URL with AWS SAM, including the alias mapping:

WebhookFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: webhook/
      Handler: index.handler
      Runtime: nodejs14.x
      AutoPublishAlias: live
      FunctionUrlConfig:
        AuthType: NONE
        Cors:
            AllowOrigins:
                - "https://example.com"

If you have existing Lambda functions in your IaC templates, you can define a new function URL with a few lines of code.

Function URL Pricing
Function URLs are included in Lambda’s request and duration pricing. For example, let’s imagine that you deploy a single Lambda function with 128 MB of memory and an average invocation time of 50 ms. The function receives five million requests every month, so the cost will be $1.00 for the requests, and $0.53 for the duration. The grand total is $1.53 per month, in the US East (N. Virginia) Region.

When to use Function URLs vs. Amazon API Gateway
Function URLs are best for use cases where you must implement a single-function microservice with a public endpoint that doesn’t require the advanced functionality of API Gateway, such as request validation, throttling, custom authorizers, custom domain names, usage plans, or caching. For example, when you are implementing webhook handlers, form validators, mobile payment processing, advertisement placement, machine learning inference, and so on. It is also the simplest way to invoke your Lambda functions during research and development without leaving the Lambda console or integrating additional services.

Amazon API Gateway is a fully managed service that makes it easy for you to create, publish, maintain, monitor, and secure APIs at any scale. Use API Gateway to take advantage of capabilities like JWT/custom authorizers, request/response validation and transformation, usage plans, built-in AWS WAF support, and so on.

Generally Available Today
Function URLs are generally available today in all AWS Regions where Lambda is available, except for the AWS China Regions. Support is also available through many AWS Lambda Partners such as Datadog, Lumigo, Pulumi, Serverless Framework, Thundra, and Dynatrace.

I’m looking forward to hearing how you’re using this new functionality to simplify your serverless architectures, especially in single-function use cases where you want to keep things simple and cost-optimized.

Check out the new Lambda Function URLs documentation.

— Alex

GitHub Availability Report: March 2022

Post Syndicated from Jakub Oleksy original https://github.blog/2022-04-06-github-availability-report-march-2022/

In March, we experienced a number of incidents that resulted in significant impact and degraded state of availability to some core GitHub services. This blog post includes a detailed follow-up on a series of incidents that occurred due to degraded database stability, and a distinct incident impacting the Actions service.

Database Stability

Last month, we experienced a number of recurring incidents that impacted the availability of our services. We want to acknowledge the impact this had on our customers, and take this opportunity during our monthly report to provide additional details as a result of further investigations and share what we have learned.

Background

The underlying theme of these issues was due to resource contention in our mysql1 cluster, which impacted the performance of a large number of our services and features during periods of peak load.

Each of these incidents resulted in a degraded state of availability for write operations on our primary services (including Git, issues, and pull requests). While some read operations were not impacted, any user who performed a write operation that involved our mysql1 cluster was affected, as the database could not handle the load.

After the other services recovered, GitHub Actions queues were saturated. We enabled the queues gradually to catch up in real time, and as a result our status page noted the multi-hour outages. When Actions are delayed, it can also impact CI completion and a host of other functions.

What we learned

These incidents were characterized by a burst in load during peak hours of GitHub traffic. During these bursts, our mysql1 cluster was not able to handle the load generated by traffic on the system and we were forced to fail-over and take other mitigations, as mentioned in the previous post.

Some of these incidents were related to our efforts to improve visibility on the database, but all of them were related to the low amount of headroom we had on our primary database and thus its susceptibility to a few poorly performing queries.

Optimizing for stability

Because of this, even after we mitigated the initial causes of downtime due to poor query performance, we were still running with low headroom and decided to take a proactive approach to managing load by intentionally slowing down services during peak hours. Furthermore, we took a calculated approach to increase capacity on the database by further optimizing queries.

Rather than risk another site outage, we established lower performance alerting thresholds on the database and proactively throttled webhooks and Actions services (the two largest drivers of automated load on the system) as we approached unsafe margins of error on March 14 14:43 UTC. We understood the potential impact to our customers, but decided it would be safer to proactively limit load on the system rather than risk another outage on multiple services.

In the meantime, we implemented a series of optimizations between March 14 and March 28 that drove queries per second on this database down by over 50% and reduced our transaction volume by 70% at peak load times. Through these performance optimizations, we became more confident in our headroom, but given ongoing investigations, we did not want to chance any unwarranted impacts.

Minimizing impact to our users

After the incidents mentioned above, we took steps to make sure we would be in a position, if necessary, to shut down any services driving high peak load. This meant taking maintenance windows for three services starting on March 24. We proactively paused migrations and team synchronization during peak load due to their potential impact.

We also took maintenance windows for GitHub Actions even though we did not actually throttle any actions and no customers were impacted during these windows. We did this in order to proactively notify customers of possible disruption. While it didn’t end up being the case, we knew we would need to throttle GitHub Actions if we saw any significant database degradation during these time windows. While this may have caused uncertainty for some customers, we wanted to prepare them for any potential impact.

Next steps

Immediate changes

In addition to the improvements mentioned above, we have significantly reduced our database performance alerting thresholds so that we are not “running hot” and will be well positioned to take action before customers are impacted.

We have also accelerated work that was already in progress to continue to shard this particular cluster and apply the learnings from this incident to other clusters that already exist outside of mysql1.

Additional technical and organizational initiatives

Due to the nature of this incident, we have also dedicated a team of engineers to study our internal processes and procedures, observability, and change release processes. While we’re still actively revisiting this incident, we feel confident we have mitigated the initial issues and we have the correct alerting and processes in place to ensure this problem is not likely to occur again.

We understand that the Actions service is critical to many of our customers. With new and ongoing investments across architecture and processes, we’ll continue to bring focus specifically to Actions reliability, including more graceful degradations when other GitHub services are experiencing issues, as well as faster recovery times.

March 29 10:26 UTC (lasting 57 minutes)

During an operation to move GitHub Actions and checks data to its own dedicated, sharded database cluster, a misconfiguration on the new database cluster caused the application to encounter errors. Once we reverted our changes, we were able to recover. This incident resulted in the failure or delay of some queued jobs for a period of time. Once mitigation was initiated, jobs that were queued during the incident were run successfully after the issue was resolved.

The Actions and checks data resides in a multi-tenant database cluster. As part of our efforts to improve reliability and scale, we have been working on functionally partitioning the Actions data to its own sharded database cluster. The switch over to the new cluster involves gradually switching over reads and then switching over writes. Immediately after switching the write traffic, we noticed Actions SLOs were breached and initiated a revert back to the old database. After we reverted back to the old database, we saw an immediate improvement in availability.

Upon further investigation, we discovered that update and delete queries were processed correctly on the new cluster, but insert queries were failing because of missing permissions on the new cluster. All changes processed on the new cluster were replicated back to the old cluster before the switch back, ensuring data integrity.

We have paused any attempts for migrations until we fully investigate and apply our learnings. Furthermore, due to the risk associated with these operations, we will no longer be attempting them during peak traffic hours, which occur between 12:00 and 21:00 UTC. From a technical perspective, we’re looking to scrutinize and improve our operational workflows for these database operations. Additionally, we are going to be performing an audit of our configurations and topology across our environment, to ensure we have properly covered them in our testing strategy. As part of these efforts, we uncovered a gap where we need to extend our pre-migration checklist with a step to verify permissions more thoroughly.

In summary

Every month we share an update on GitHub’s availability, including a description of any incidents that may have occurred and an update on how we are evolving our engineering systems and practices in response. Our hope is that by increasing our transparency and sharing what we’ve learned, everyone can gain from our experiences. At GitHub, we take the trust you place in us very seriously, and we hope this is a way for you to help hold us accountable for continuously improving our operational excellence, as well as our product functionality.

To learn more about our efforts to make GitHub more resilient every day, check out the GitHub engineering blog.

Prevent the introduction of known vulnerabilities into your code

Post Syndicated from Courtney Claessens original https://github.blog/2022-04-06-prevent-introduction-known-vulnerabilities-into-your-code/

Understanding your supply chain is critical to maintaining the security of your software. Dependabot already alerts you when vulnerabilities are found in your existing dependencies, but what if you add a new dependency with a vulnerability? With the dependency review action, you can proactively block pull requests that introduce dependencies with known vulnerabilities.

How it works

The GitHub Action automates finding and blocking vulnerabilities that are currently only displayed in the rich diff of a pull request. When you add the dependency review action to your repository, it will scan your pull requests for dependency changes. Then, it will check the GitHub Advisory Database to see if any of the new dependencies have existing vulnerabilities. If they do, the action will raise an error so that you can see which dependency has a vulnerability and implement the fix with the contextual intelligence provided. The action is supported by a new API endpoint that diffs the dependencies between any two revisions.

Demo of dependency review enforcement

The action can be found on GitHub Marketplace and in your repository’s Actions tab under the Security heading. It is available for all public repositories, as well as private repositories that have Github Advanced Security licensed.

We’re continuously improving the experience

While we’re currently in public beta, we’ll be adding functionality for you to have more control over what causes the action to fail and can set criteria on the vulnerability severity, license type, or other factors We’re also improving how failed action runs are surfaced in the UI and increasing flexibility around when it’s executed.

If you have feedback or questions

We’re very keen to hear any and all feedback! Pop into the feedback discussion, and let us know how the new action is working for you, and how you’d like to see it grow.

For more information, visit the action and the documentation.

The Forecast Is Flipped: Flipping L&D in New Hire Training

Post Syndicated from Megan Yawor original https://blog.rapid7.com/2022/04/06/the-forecast-is-flipped-flipping-l-d-in-new-hire-training/

The Forecast Is Flipped: Flipping L&D in New Hire Training

Rapid7’s onboarding program, Making the Band, first came to the stage in the fall of 2017 when the original 2-week, video-based program evolved into a dynamic 90-day experience. The updated program delivered learnings to new hires through digital self-paced content and a 2-day live training focused on tactical elements, as well as foundational company knowledge.

However, in the spirit of Never Done, the Rapid7 People Development team challenged convention and recently evolved the onboarding program to address the needs of our evolving business and the future of work.

After analyzing the current state of the program, People Development realized that what was needed was a streamlined experience that supported and connected a growing, hybrid company, as well as one that aligned and prepared employees for role-specific success, regardless of their location or position.

The goal of this work was to reimagine the current onboarding process in a way that sustained the essence of the original 2017 experience, but also adapted and scaled as we onboarded a global new hire population. This would be achieved by keeping ALL Moose in mind, curating opportunities that built connections in this new normal, emphasizing the importance and impact of our culture, and seamlessly guiding new Moose through the fundamentals in order to shorten their time to impact.

Flipped learning: Delivering a vision for evolution

A primary focus for Rapid7’s People Strategy team is to help our Moose build the best career experience. Onboarding is the first step to building this experience. Denee D’Andrea, Sr. People Development Specialist and visionary behind the evolved program, recognized this and wanted to ensure that the program delivered the right content at the right time. This resulted in a new global onboarding experience that extended beyond one-and-done live sessions and self-paced content to a full, multifaceted experience, using blended learning and flipped-classroom approaches.

D’Andrea’s new onboarding vision focused on 3 key phases grounded in our Core Values: Connection, Impact in Your Role, and Embodiment of Bring You.

Rapid7 recognized creating connections was a key element of success while working in a hybrid environment. Because of that, D’Andrea partnered with organizations across the business to ensure opportunities for connection were threaded throughout the entire program. The Connection piece was fostered using the flipped approach – meaning the majority of “classroom time” was spent teaching through discussions led by Rapid7 Culture Ambassadors (our own Moose!) and subject matter experts.

Additionally, to stay true to the Challenge Convention mindset, I created a fully virtual, interactive multi-phase challenge with the goal of further encouraging connections. By navigating animations, digital games, and customized puzzles and codes, new hires were introduced to the security landscape, customer challenges, and Rapid7’s portfolio. The intentional design of the challenge provided the space and activities to encourage discussion and collaboration towards a common goal. New Moose would not only connect with each other (regardless of their location) but also feel like they were connecting with Rapid7’s history, culture, and Core Values.

Next, Impact in your Role focused on encouraging the Never Done mindset and highlighted the connection between individual growth and the success of our teams, customers, and the company as a whole. This mindset was woven throughout the entire 90 days, both within “classroom time” and in the on-demand, self-paced digital content. To create the most impactful learning environment, the team again utilized the flipped classroom. Live sessions provided collaborative learning and discussion opportunities, and then digital flipped-learning materials further fleshed out the learnings. This design ensured New Moose not only benefited from social learning but also fostered accountability to their development both during and beyond the onboarding experience.

And finally, Embodiment of Bring You. At Rapid7, we truly want our people to bring their authentic selves to their work because we believe that these unique perspectives, ideas, and values enable us to Challenge Convention and enhance the work we do. The final piece of the program, an experiential learning challenge, encouraged New Moose to embrace the value Bring You while collaborating with their cohort and Culture Ambassadors to build their cross-functional network.

The New New Moose

On January 3, 2022, this new program launched, for the first time, with a cohort of 43 New Moose. Since then, over 370 Moose, globally, have engaged with the program.

And how has it been? EPIC.

Making the Band is where our New Moose start building the career experience of a lifetime.This program not only motivates and empowers employees to embody our Core Values but also helps them to understand that we are #onemoose, and when we Impact Together, we accelerate together.

Check out what some of our New Moose are saying!

The program

  • “AWESOME… Onboarding has been an incredible experience so far… One of the best onboarding experiences I have had in my professional career… I believe Rapid7 has an amazing and talented team facilitating the onboarding experience.”

Virtual, interactive challenge (“Insuring” the Security of MiracleMoose Insurance)

  • “That was fun and engaging… The group roles/participation were great…it was a fun way to collaborate with my fellow new Moose… and the content was highly engaging which provided a meaningful intro to Rapid7’s portfolio and the customer while also fostering communication and critical thinking skills.”

Stay tuned over the next several months to dive deeper into how People Development will be introducing flipped content and other innovative practices into all of their programs for 2022 and beyond in our blog series, “The Forecast Is Flipped.”

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Getting Started with Event-Driven Architecture

Post Syndicated from Talia Nassi original https://aws.amazon.com/blogs/compute/getting-started-with-event-driven-architecture/

In modern application development, event-driven architecture is becoming more prominent because it can make building applications in the cloud easier. Event-driven architecture can allow you to decouple your services, which increases developer velocity, and can make it easier for you to debug applications. It also can help remove the bottleneck that occurs when features expand across different teams, which allows teams to progress more independently.

One way to think about how an application works is as a system that reacts to events from other places, like from within your application. In this approach, you focus on the system’s interaction with its surroundings as a transmission of events. The application receives and creates events. Inputs to the application and outputs from the application act as events. At its core, this is event-driven architecture.

API-driven architecture vs. event-driven architecture

Commands/APIs Events
Synchronous Asynchronous

Has an intent

Directed to a target

It’s a fact

Happened in the past

“CreateAccount”

“AddProduct”

“AccountCreated”

“ProductAdded”

A common way of making components of an application work together is through an API-driven, request-response architecture where you have requests and responses. For example, you query a list of orders from an Orders API, and the Orders API responds with a list of orders. This is an example of synchronous architecture. The system asking for the orders waits for the response. You cannot move on until the response comes back. In this approach, you send commands that are directed to a target (for example, “place this order” or “add this record to the database”).

sync vs async

In a synchronous model, the client makes a request to Service A. Service A calls Service B, but then Service A waits for Service B to respond before it continues on and eventually responds to the client.

In asynchronous, event-driven architecture, there is no response path. The service surfaces the event and then immediately moves forward. The trade-off here is that there’s no direct channel for Service B to pass back information to Service A, besides confirming it received the event. But in many cases, you don’t need that explicit coupling between the request and response channels.

An event is something that happened. For example, a new account is created, or an item is dropped into an Amazon S3 bucket. Events are immutable, which means you cannot change them. Once an event happens, you cannot undo it. For example, if there is an event raised when an order is placed, there can be another event for an order being cancelled. Events can come from various places such as messaging systems or databases.

Events are JSON objects that tell you information about something that happened in your application. In event-driven architecture, events represent facts. Each component of the application raises an event whenever anything changes. Other components listen and decide what to do with it and how they would like to react.

event

In the event above, S3 raises the event when you put the image into an Amazon S3 bucket. The event source is an S3 bucket named sam-app-sourcebucket. The object that is put into the bucket is called “brad.jpeg”.

Request-driven applications typically use directed commands to coordinate downstream functions to complete an activity and are often tightly coupled. This makes it harder to determine when errors occur in your application. Event-driven applications create events that are observable by other services and systems. However, the event producer is unaware of which consumers, if any, are listening. Typically, these are loosely coupled.

Events are observable. Any service that is authorized can watch an event. Consider a coffee shop example where there is a barista, who makes coffee, and a pastry chef, who makes pastries. When a customer enters the coffee shop and orders a cup of coffee, the barista starts to make the coffee, and the pastry chef takes no action.

However, if a customer comes in to the coffee shop and orders a chocolate croissant, then the pastry chef starts making the chocolate croissant, and the barista takes no action. The pastry chef is only interested in orders relating to pastries and the barista is only interested in events relating to coffee.

In an ecommerce application, like Amazon.com, there are different departments that respond to different events. You can place orders through Whole Foods, Amazon Fresh, and Amazon.com. When you place an order with Amazon Fresh, the subscribers to that event take action and fulfill your order.

event

Event-driven architecture and command-driven architecture also differ in the ways that they store state. In a typical command-driven architecture, you have only one component store a particular piece of data, and other components ask that component for the data when needed.

In event-driven architecture, every component stores all the data it needs and listens to update events for that data. In command-driven architecture, the component that stores the data is responsible for updating it. In event-driven architecture, all it has to do is ensure new events are raised on the updates.

Benefits of using event-driven architecture

Decoupling event sources and event targets

Many applications are built in a monolith, where the components are tightly coupled, and are highly dependent on each other. This proves to be problematic when there are bugs and you are trying to pinpoint exactly what part of the application is failing. Decoupled architectures are composed of components or services that are loosely coupled. In an event-driven, decoupled architecture, you broadcast events without caring who responds to them. This saves time because events can be queued and forwarded whenever the receiver is ready to process them. This allows for building scalable, highly modifiable systems.

Decoupled applications enable teams to act more independently, which increases their velocity. For example, with an API-based integration, if my team wants to know about some change that happened in another team’s microservice, I have to ask that team to make an API call to my service. That means I have to deal with authentication, coordination with the other team over the structure of the API call, etc. This causes back and forth between teams, which slows down development time. With an event-driven application, you can subscribe to events sent from a microservice and the event router (for example, Amazon EventBridge) takes care of routing the event and handling authentication.

Decoupled applications also allow you to build new features faster. Adding new features or extending existing ones is simpler with event-driven architectures. This is because you only have to choose the event you need to trigger your new feature, and subscribe to it. There’s no need to modify any of your existing services to add new functionality.

Write less code

When you build applications using event-driven architecture, often you write less code because you only need to consider new events, as well as which service is subscribed to those events. For example, if you are building new features for your application, all you have to do is consider the existing events and then add senders and receivers as necessary. In this way, you speed up development time because each functional unit is smaller and there is often less code.

Better extensibility

In the example above, you built a highly extensible application. Other teams can extend features and add functionality without impacting other microservices. By publishing events using EventBridge, this application integrates with existing systems, but also enables any future application to integrate as an event consumer. Producers of events have no knowledge of event consumers, which can help simplify the microservice logic.

Enhancing team collaboration

A common process to build applications is to work with your product managers and business stakeholders to gather requirements. Developers then translate those requirements into code. However, there may be a disconnect between the product requirements and the code. When you use events, everyone in the business understands the logic. You define the events in an application (for example, a customer adds an item to their shopping cart or a customer account is created) and that becomes your product requirements. Whenever that action happens, it produces an event, and whoever is interested can take action on that event.

For example, a marketing manager could be interested whenever a customer creates a new account. One way to choreograph this in event-driven architecture is to have a Marketing event bus that listens for the New Account event. There could also be other teams that are interested, such as the Analytics team, who also subscribe to that event. Each team/service can subscribe to events that are relevant to them. Event-driven architecture is a great way for businesses to describe their business problems and represent them.

Conclusion

This post introduces events, and then compares event-driven architecture to command-driven, request-response architecture. It also explains the benefits of event-driven architecture, including decoupling event sources and targets, writing less code, having better extensibility, and enhancing team collaboration.

For more serverless learning resources, visit Serverless Land.

Let’s Architect! Architecting microservices with containers

Post Syndicated from Luca Mezzalira original https://aws.amazon.com/blogs/architecture/lets-architect-architecting-microservices-with-containers/

Microservices structure an application as a set of independently deployable services. They speed up software development and allow architects to quickly update systems to adhere to changing business requirements.

According to best practices, the different services should be loosely coupled, organized around business capabilities, independently deployable, and owned by a single team. If applied correctly, there are multiple advantages to using microservices. However, working with microservices can also bring challenges. In this edition of Let’s Architect!, we explore the advantages, mental models, and challenges deriving from microservices with containers.

Application integration patterns for microservices

As Tim Bray said in his time with AWS, “If your application is cloud native, large scale, or distributed, and doesn’t include a messaging component, that’s probably a bug.”

This video evaluates several design patterns based on messaging and shows you how to implement them in your workloads to achieve the full capabilities of microservices. You’ll learn some fundamental application integration patterns and some of the benefits that asynchronous messaging can have over REST APIs for communication between microservices.

The scatter-gather pattern scales parallel processing across nodes and aggregates the results in a queue

The scatter-gather pattern scales parallel processing across nodes and aggregates the results in a queue

Distributed monitoring

Customers often cite monitoring as one of the main challenges while working with containers. Monitoring collects operational data as logs, metrics, events, and traces to identify and respond to issues quickly and minimize disruptions.

This whitepaper covers cross-service challenges in microservices, including service discovery, distributed monitoring, and auditing. You’ll learn about the role of DNS and service meshes in interservice communication and discovery and the tools available for monitoring your clusters that run containers and for logging.

This view from AWS X-Ray shows how a request can be tracked across different services. This is implemented by taking advantage of correlation IDs

This view from AWS X-Ray shows how a request can be tracked across different services. This is implemented by taking advantage of correlation IDs

Create a pipeline with canary deployments for Amazon ECS using AWS App Mesh

When architects deploy a new version of an application, they want to test it on a set of users before routing all the traffic to the new version. This is known as a “canary deployment.” A canary deployment can automatically switch traffic back to the old version if some inconsistencies are detected. This decreases the impact of the bug(s) introduced in the new release. For microservices, this is helpful when testing a complex distributed system because you can send a percentage of traffic to newer versions in a controlled manner.

A service mesh provides application-level networking so your services can communicate with each other across multiple types of compute infrastructure. This blog post shows how to use AWS App Mesh to implement a canary deployment strategy using AWS Step Functions for orchestrating the different steps during testing and AWS Code Pipeline for continuous delivery of each microservice.

An overview of the architecture used to create the pipeline and perform the canary deployments

An overview of the architecture used to create the pipeline and perform the canary deployments

Running microservices in Amazon EKS with AWS App Mesh and Kong

Distributed architectures bring up several questions. How do we expose our APIs towards client-side applications? How do our microservices communicate?

This blog post answers these questions with a solution that uses Amazon Elastic Kubernetes Service (Amazon EKS) in conjunction with AWS App Mesh. This solution helps you manage the security and discoverability of microservices, and Kong protects your service mesh and runs side by side with your application services.

The Kong for Kubernetes architecture can be implemented using Amazon EKS and AWS App Mesh

The Kong for Kubernetes architecture can be implemented using Amazon EKS and AWS App Mesh

See you next time!

See you in a couple of weeks when we discuss open source technologies on AWS!

Looking for more architecture content? AWS Architecture Center provides reference architecture diagrams, vetted architecture solutions, Well-Architected best practices, patterns, icons, and more!

Other posts in this series

MDR Plus Threat Intel: 414 New Detections in 251 Days (You’re Welcome)

Post Syndicated from Sam Adams original https://blog.rapid7.com/2022/04/06/mdr-plus-threat-intel-414-new-detections-in-251-days-youre-welcome/

MDR Plus Threat Intel: 414 New Detections in 251 Days (You’re Welcome)

Last summer, Rapid7 acquired IntSights and its advanced external threat intelligence solution (now Threat Command by Rapid7). Threat Command monitors hundreds of thousands of sources across the clear, deep, and dark web, identifying malicious actors and notifying customers of potential attacks against their organizations.

The reason for the acquisition? With these external intelligence sources built into InsightIDR, its breadth of high-fidelity, low-noise detections would be unmatched.

Detections have been a Rapid7 thing since the start.

In an industry focused on ingesting data – and placing the burden on security teams to write their own detections – we went another way. We went detections first, delivering the most robust set of actionable detections out of the box.

Today, our detections library includes threat intelligence from our open-source communities, advanced attack surface mapping, proprietary machine learning, research projects, real-world follow-the-sun security operations center (SOC) experience, and 2.1+ trillion weekly security events observed across our detection and response (D&R) platform.

Now, Threat Command’s threat intelligence platform (TIP) content is integrated with our leading detection and response products and services. You get earlier threat identification and faster remediation.

MDR and InsightIDR customers have an even larger, expertly curated library

Right now, Rapid7 customers can find a lot more needles in haystacks. And we’ve made sure you can spot them quickly, easily, and reliably.

Our Threat Intelligence and Detection Engineering Team (TIDE) has done its work developing signatures and analytic detections for existing and emerging threats. TIDE analysts continuously provide InsightIDR users and managed detection and response (MDR) SOC analysts with the surrounding context needed to defend against threats with new detection mechanisms for vulnerability exploits and attack campaigns.

The detections are for newcomers as well as familiar names like the notorious Russian hacking group EvilCorp. As always, detections ensure coverage for various indicators of compromise (IOCs) that they and other attackers use in the wild.

Think of us as your research and execution team: As additional IOCs are added to the Rapid7 Threat Command Threat Library, they are automatically tested and applied to your logs to create alerts when identified.

What’s better and better, by the numbers

Now, InsightIDR has your back with:

  • 138 threats powered by Threat Command’s Threat Library
  • 414 detection rules powered by dynamic IOC feeds
  • Monitoring for all IOCs associated with each threat actor is automatic as they are added to the Threat Library

The mission is always to deliver more actionable alerts (with recommendations) and to reduce noise. So our TIDE Team tests IOCs and disables those we find to be unsuitable for alerting.

And this is just the beginning: All detections improve in fidelity over time as our MDR analysts inform the threat intelligence team of rule suppressions to provide a tailored approach for customers, add granularity, reduce noise, and avoid recurrency. And as Threat Command adds IOCs, they’ll turn into meticulous, out-of-the-box detections – whether you use InsightIDR, rely on our MDR SOC analysts, or collaborate with us to keep your environment secure.

If you’re an MDR customer or just considering it, here are other numbers to know:

  • With a 95% 4-year analyst retention rate, Rapid7 is an employer of choice during the cybersecurity staffing crisis and The Great Resignation
  • Our team of 24/7/365  global SOC analysts are proven threat hunters and DFIR experts
  • Together, the staff has a combined  500+ security certifications

Now, with even more detections, the strongest back-end system capturing threats as they evolve, and unmatched knowledge in the field, you can level up your D&R program with Rapid7 InsightIDR — or a partnership with the best-in-breed MDR analyst teams out there.

Additional reading:

NEVER MISS A BLOG

Get the latest stories, expertise, and news about security today.

Emacs 28.1 released

Post Syndicated from original https://lwn.net/Articles/890405/

Version 28.1 of the
Emacs editor has been released. The announcement says little about what’s
in this release, but there are a lot of details in the NEWS file.
Significant changes include native compilation of ELisp files, support for
running the editor in a seccomp() sandbox, improved emoji support,
and much more. Wayland support did not
make it into this release, but is already merged for version 29.

Security updates for Wednesday

Post Syndicated from original https://lwn.net/Articles/890404/

Security updates have been issued by Arch Linux (rizin), Fedora (fish, gdal, mingw-fribidi, mingw-gdal, mingw-openexr, mingw-python-pillow, mingw-python3, and python-pillow), Mageia (chromium-browser-stable), Oracle (Extended Lifecycle Support (ELS) Unbreakable Enterprise kernel and kernel), Red Hat (kernel, kernel-rt, and Red Hat OpenStack Platform 16.2 (python-waitress)), Scientific Linux (kernel), Slackware (mozilla), SUSE (mozilla-nss), and Ubuntu (h2database).

Конкурсът на „Алеф” се разпространи в осем държави

Post Syndicated from original https://bivol.bg/%D0%BA%D0%BE%D0%BD%D0%BA%D1%83%D1%80%D1%81%D1%8A%D1%82-%D0%BD%D0%B0-%D0%B0%D0%BB%D0%B5%D1%84-%D1%81%D0%B5-%D1%80%D0%B0%D0%B7%D0%BF%D1%80%D0%BE%D1%81%D1%82%D1%80%D0%B0%D0%BD%D0%B8.html

сряда 6 април 2022


Младежка надпревара популяризира зад граница подвига на България за спасяването на евреите Две авторитетни журита ще оценяват литературните творби Изтече крайният срок за включване в Деветия международен литературен младежки конкурс…

[$] Debian still having trouble with merged /usr

Post Syndicated from original https://lwn.net/Articles/890219/

The addition of the “/usr merge” feature has been something of longstanding mess
in the Debian world. It seems like a relatively innocuous change, which
is in keeping with the practice of most other distributions at this point; it effectively
eliminates the top-level /bin, /sbin, and /lib*
directories in order to move their contents to the corresponding locations
under /usr. But ever since we first covered the feature introduction for
Debian—more than six years ago—it has a been a recurring series of
headaches within that community. Recent events have seemingly simply
prolonged the pain, though perhaps the end is in sight.

Rust Lang Roadmap for 2024

Post Syndicated from original https://lwn.net/Articles/890293/

The Rust language team has put up a
blog entry describing the plans for the language over the next couple
of years or so.

More precise analyses, less rigamarole: Make the compiler
better able to recognize when code is correct via improvements to
the borrow checker, type inference, and so forth. Identify and
eliminate “boilerplate” patterns like having to copy-and-paste the
same set of where clauses everywhere.

The collective thoughts of the interwebz